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PREFACE 


Sky lab was the mosL comprehensive manned space program completed 
to date, involving unprecedented numbers of experiments, government 
agencies, contractors and supporting personnel. Ninety-four experiments, 
plus several experimental operational instruments and twenty-six science 
demonstrations, were developed, integrated with Sky lab, and flown. A 
majority of these were individual experiments, although some (e.g., 
earth resources and space materials processing experiments) were associ- 
ated with discipline-oriented facilities provided for scientr ic users 
by Sky lab. Experiment data gathered aboard Sky lab was supplied to over 
two hundred and fifty scientists from the United States and nineteen 
other countries. 

The many interfaces involved in the development and integration 
of these experiments imposed new burdens upon the "standard" methods 
and techniques that had evolved from earlier space programs. As a 
result, many changes were made, and many lessons learned, throughout 
the course of the Sky lab Program. For example, new types of documen- 
tation were established, design review and configuration management 
techniques were improved and mission support activities took on new 
dimensions. This Experimenters' Reference records the Skvlab experience 
in experiment management, including lessons learned and recommendations 
for improved cost-effectiveness, to facilitate the transfer of this 
knowledge to experimenters in future manned space programs. 
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i>e FiNi riONS 

Ac c op t a lie e - An official act by the Experiment Development Center to 
accept transfer of accountability, title, and delivery of an etui item 
o 1 liardware or software, whether procured on contract or in-house. 

Ac c o p t anc e lost — ihe formal assessment or testing accomplished in 
accordance with Part II of an end item specification to verily the 
performance, configuration, and manufacture of an end item (1) at the 
time of its delivery and acceptance by the Government, or (2) for 
delivery to another NASA Center. 

Ac tivation - Hie activities associated with originally placing an 
orbital vehicle or ground facility in operational condition. 

Baseline - An approved and defined technical description providing a 
point ol departure for control of future changes. 

cluster - ihe orbital assembly constituting the complete conf igurat ion 
lor manned Sky lab missions, including all modules of the unmanned 
laboratory plus a docked Command and Service Module. 

) 2 

Crew Compartment Fit and Funetion (C~F~) - One ot the final check- 
outs per I orm a! during hardware integration. Flight crew members in- 
spect the carrier for proper hardware integration, accessibility, and 
sa fotv cons i derat ions . 

he 1. i v e i \ - Tile physical transier oi hardware from one site to another. 
Includes transier of response hi l i tv ior hardware custodianship (also 
see Ac c e p 1 . i n c e ) • 

End Item - An article ol hardware or software which is deliverable by 
NASA or a contractor as a complete item as identified, defined and 
sc bed u led . 

£, D, I * A part of the payload devoted to the investigation of 
scientific or engineering phenomena. Sometimes used as synonymous 
with ins tinmen t ; however, instrument gene* rally refers only* to the 
operating i light hardware, whereas experiment refers to the combina- 
tion ol ail associated hardware plus the use of the data to satisfy an 
objective. 


Cronn I Support Equipment - Special equipment r.quir.d for smiuiw 
I*, si in. , hand 1 i ng , mai nt a i n i ng , a;ui /or 1 ransport i ng tin- v >qx r i r.u n t 
.'.arehari- during ground operations. 




High-Fidelity Mockup - Training hardware that is essentially identical 
to flight hardware in size, shape, and appearance and provides crew 
interfaces (switches, etc.) but need not be operational. 

Instrument - An item of hardware designed to perform a specific scientific 
or engineering function in support of an experiment objective (also see 
Experiment) . 

Interface - A region common to two or more elements, systems, projects 
or programs and characterized by mutual physical, functional, environ- 
mental, operational, and/or procedural properties. 

Integration - Activities that are performed to assure physical and 
functional compatibility of an experiment with other experiments, the 
module, and the overall mission. Also the physical mating and testing 
of a combined system (e.g. module and experiments). 

Mission - A single spaceflight from launch to landing, and its objectives. 

Module - A major element of the payload or spacecraft, which carries 
experiments and support systems designed to meet mission objectives. 

Near-Real Time - A short period of time, (normally within 24 hours) 
after actual occurrence of a mission event. 

Open Item - A question or problem which is unresolved, and requires 
action to ensure its resolution. 

Orbital Facility - A group of instruments designed to investigate vari- 
ous parameters of a common subject or discipline. 

Qualification - Determination that an article or material is capable 
of meeting all design and performance requirements established for the 
item. An item can be qualified by test, by analysis, or by similarity 
to a qualified item. 

Single Failure Point - A single item of hardware having an independent fail- 
ure mode which would result in the functional loss of a system. Examples 
are nonredundant valves, regulators, pumps, motors, switches, relays, 
transistors, resistors, diodes, or a single path of passive electrical 
hardware (e.g., wiring, solder joint, connectors, etc.) that could open or 
short circuit. 

Waiver - A written authorization to accept an end item or other designated 
item which, during manufacture or after having been submitted for inspec- 
tion, is found to depart from specified requirements but is considered 
suitabLe for use n as is ‘ or after rework by an approved method. 
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cV 
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SECTION I. 


INTRODUCTION 


A. Purpose 

This document is intended to familiarize prospective partici- 
pants in future manned space programs with the methods and techniques 
for experiment development and integration that evolved during the 
Skylab Program. Future programs may not adopt identical procedures 
but insight into the Skylab experience, including the lessons learned, 
will be of value as a reference for scientific investigators, experi> 
ment developers, and integrators who face similar tasks in the future. 

E. Scope 

The Experimenter ’ s Reference outlines the full spectrum of 
experiment-related responsibilities, activities and events as they 
were planned and executed in the Skylab Program, The planning and 
the execution sometimes varied; exceptions and variations were common 
as the program developed. This is not a history of such deviations, 
but rather a compilation of those methods and techniques which experi- 
ence proved to be most effective for Skylab. 

The major activities and events that involve experiments, and 
their interrelationships, are illustrated in functional flow charts 
for the overall program and for each of its major phases. An over- 
view is given of the National Aeronautics and Space Atlminis tration 
(NASA) management roles and responsibilities. The alternative 
approaches of providing single experiments for individual investiga- 
tors, versus a multi-instrument orbital facility with many "users,” 
are discussed. The evolution of the experiment and its hardware, 
and their integration with Skylab, are traced from initial concept 
through delivery, integration testing, mission operations, data analy- 
sis and reports. Configuration control and the influence of special 
disciplines (safety, reliability, maintainability, quality assurance 
etc.) are separately treated. Public relations aspects are also 
discussed. Skylab lessons learned are incorporated in the form of 
specific "Recommendations’* , interspersed at appropriate points through- 
out the text. (Additional lessons learned across all program discip- 
lines, as compiled by NASA Headquarters and the various NASA centers, 
may be found in References 1 through 4.) S 

The main text is intentionally concise. Additional details, 
where considered appropriate, are provided in separate appendices, 
tor example, major experiment-related documents referred to through- 
out the text are described in detail in Appendix A* 
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Program General Flow 


noral functional flow o£ activities ^ events that 

■ i " r ; , io 1 lowed a fairlv standardized pattern 
(fL-i.ro 1) whether tor an individual experiment or tor an instrument 
“mi f pa t of a facility. Distinct pc.gr. Phases, a. Went! led 
1° Ti« l, arc amplified i" actions III ihm* VIII; aettetue 
vhlch extended through many phases o£ the program are discuss, 
separately in sections II and IX through XI and in Appends* BA 
second -level lion for each major program phase is included at t 
inning of the applicable section to lll.tr... Ue re ationsh P s 
of activities discussed within that section. A waterfall chart or 
experiment program elements (figure 2) depicts the overall Skylab 
experiment program in greater detail. 
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EXPERIMENT -RELATED PROGRAM ELEMENTS 
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SECTION II. PROGRAM MANAGEMENT 


In general, management systems and techniques employed by NASA for 
the Skylab Program were outgrowths from those developed on Previous man- 
ned space programs. They naturally evolved and changed during Skylab, 
further variations can be anticipated to accommodate the unique require- 
ments of future programs. In recognition of this fact, an effort has 
been made to identify the necessary management functions in a general 
way, regardless of who may be assigned to carry them out. 

The areas of general responsibility for a space experiment pro- 
gram are: 1) program direction, 2) hardware development, 3) integration, 
4) launch operations, 5) mission operations, and 6) analysis and re P°^'_ 
ing. For Skylab, NASA Headquarters retained the program direction respon 
sibility, and delegated the other roles to individual NASA centers. 

RECOMMENDATION: At the outset of a program, publish and 

enforce clearly defined intercenter and intracenter author- 
ities and responsibilities for all program elements. 

A, Program Direction 

NASA Headquarters provided the initial planning and the top-level 
direction for all program aspects. A Headquarters Program Office (t e 
Skylab Program Director and a limited staff) exercised this management 
role by means of guidelines and directives to the NASA Center Program 
Managers, and overall control of funds and schedules. Major decisions 
involving program and mission objectives, experiment selections and 
flight assignments, funding, and milestone schedules were made by Head- 
quarters, with due consideration for inputs from the appropriate centers. 

Various offices at Headquarters served as Sponsoring Program Offices 
(SPO) for individual Skylab experiments (see Section III B). A Manned 
Space Flight Experiments Board (MS FEB) , composed of representatives of 
various NASA and Department of Defense organizations, performed a con- 
tinuing advisory function for the Associate Administrator for Manned 
Space Flight, relative to major experiment decisions. (MSFEB covered not 
only Skylab, but all current and contemplated manned space flight exper- 
iment programs.) 

B. Hardware Development Centers 

Each major group of associated hardware end items (e.g., an ex- 
periment or module) was assigned to an appropriate NASA center for 
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development. Any existing center could be selcc 
nature of the end items and center capabilities, 


I, depending on the 


1. Experiment Development Center . The Experiment Development 
Center (EDC) was responsible for management o r the design, development, 
testing, fabrication, qualification and delivery of the basic instrument, 
supporting hardware and experiment-peculiar ground support equipment (GSE), 
Following delivery, the EDC monitored experiment performance and provided 
technical consultation to the module development and operational centers 
throughout postacceptance testing and mission operations. In many cases 
the EDC utilized a development contractor to augment its capabilities. 

The organization (government or contractor) that actually produced the 
experiment hardware was referred to as the Experiment Developer (ED). 

EDCs for Skylab experiments included: George C. Marshall Space Flight 

Center (MSFC), Lyndon B. Johnson Space Center (JSC), Ames Research 
Center (ARC), and Langley Research Center (LaRC). Other government 
agencies, including the Department of Transportation, the United States 
Air Force, and the Naval Research Laboratory, performed the EDC functions 
for certain experiments. Specific NASA centers were assigned to work 
with these organizations, acting as "proxy” EDCs to eliminate any 
potential difficulties due to management and reporting technique varia- 
tions utilized by different government agencies. 

2. Module Development Center . The Module Development Center 
had the same responsibilities relative to the module that the EDC had 
for the experiment. In addition, the module development center managed 
the installation and integration testing of the experiment hardware prior 
to module delivery. The actual hardware was developed by contractors 
under the direction of the center project offices. JSC was the Command 
and Service Module development center and MSFC was the development center 
for the other Skylab modules. 


C. Integration Center 

This center was responsible for overall Skylab systems engineer- 
ing and integration, which included managing experiment interfaces with 
the total program. The Integration Center maintained a continuing com- 
patibility assessment to assure that all experiments under its cognizance 
were designed, fabricated, tested and operated in complete compatibility 
with all program and experiment requirements; it also participated in the 
resolution of interface problems that arose. MSFC was the Integration 
Center for Skylab and utilized the supporting services of a Systems Engi- 
neering and Integration Contractor. 

In general, experiment integration responsibility was assigned to 
the center developing the module that would carry the experiment. Thus 
MSFC was also the Experiment Integration Center (EIC) for all Skylab 
flight experiments except those in the JSC-developed Command and Service 
Module, or aw procedural experiments involving no special hardware. 
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Launch Operations Center 

This center received the integrated modules and launch vehicle 
stages and performed final assembly, test and closeout to ensure that 
the integrated system vas ready for launch. The minimum requirements 
for the final integrated systems test were provided by the Integration 
Center to the Launch Operations Center. Launch was controlled from this 
center through countdown and liftoff. Following liftoff, control of the 
mission shifted to the Mission Operations Center. The John F. Kennedy 
Space Center (KSC) was the Launch Operations Center for Sky lab. 

E. Mission Operations Center 


This center was responsible for controlling the mission to 
ensure that mission objectives were satisfied. Prior to launch, this 
center provided crew training and prepared flight planning and mission 
operations documentation. After launch it controlled the mission by 
monitoring all systems and updating preplanned crew activities as 
required. This center was also responsible for recovery operations 
and data dissemination (see Sections VII and VIII). The Sky lab Mission 
Operations Center was JSC. 

F . Cost and Schedule Control 


Cost and schedule considerations were an important factor in 
selecting the experiments and continuing them in the program. Intense 
management scrutiny was brought to bear on those experiments that had 
repeated overruns of estimated costs or delays in meeting established 
milestones, which in turn added cost. 

The NASA Office of Manned Space Flight (OMSF ) , through the ^ 
Skylab Program Office at Headquarters, exercised overall control ot 
Skylab budgets, costs and milestone event schedules. A Program 
Operating Plan (POP), compiled and maintained at Headquarters, 
reflected experiment resources commitments as originally approved in 
the Experiment Implementation Plan and subsequently revised by approval 
of inputs submitted by the cognizant centers. The POP was the authori- 
tative summary of program funding and schedules. 

RECOMMENDATION: Prior to approval of an experiment for 

development, insist upon sufficient definition to pro- 
vide realistic estimates of cost ceilings. For this 
purpose, final approval might be withheld until after 
Preliminary Design Review; or funding could be reviewed 
and approved in inc remen tal stages. 
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SECTION III. EXPERIMENT DEFINITION 


Experiments proposed for the Skylab Program varied from new in- 
vestigations to re flight of experiments fi n other programs. Some, 
developed during previous programs, had f ght hardware already avail- 
able, while others were only concepts and cheir hardware designs had not 
yet begun. The selection process, (see figure 3) was designed to en- 
sure that experiments approved for Skylab had been thoroughly evaluated 
on the basis of scientific merit and compatibility with the programs 
objectives, capabilities, schedules and funding. The current (post- 
Skylab) NASA selection process is described in detail in Reference 5, 
and reflects the Skylab experience. 

A. Conceptual Approaches 

Skylab experiment concepts were generated and implemented by 
either of two approaches. Where an individual scientist conceived an 
acceptable investigation of a specific scientific objective, a single 
experiment was generally developed to satisfy that objective, and the 
originating scientist was identified as the Principal Investigator (PI). 
Most of the experiments were generated in this way. The other approach 
(which gained increasing favor during the Skylab Program) was that of 
implementing an "Orbital Experiment Facility", comprising a group of 
associated instruments dedicated to general investigations of a parti- 
cular scientific discipline, such as earth resources or materials pro- 
cessing in space. Facility instruments were generally conceived by a 
small group or committee of scientists versed in the needs of the dis- 
cipline involved. When the facility concept or preliminary design had 
progressed to the point where its capabilities were reasonably well 
defined, an Announcement of Flight Opportunity (AFO) was issued to 
potential "users" throughout the world. Interested scientists responded 
with proposals for using the facility to gather data for their specific 
investigat ions . Accepted proposals were contractually implemented with 
the users by the EDC. A NASA Project Scientist at the EDC performed the 
PI functions (and represented the users) for each facility instrument. 
The chief advantages of the facility approach are: much broader usage 

of the instruments and data, and the fact that all the user scientists 
need not be directly involved during the full program duration. 

B. Sponsoring Program Office 

Each experiment required a Sponsoring Program Office to manage 
the conceptual identification and feasibility phase of the experiment 
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EXPERIMENT DEFINITION 
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do l ini t ion. For Sky lab, the NASA sponsoring offices were tin* Office of 
Manned Space Flight (OMSF) , the Office of Space Science Applications 
(OSSA), and the Office of Advanced Research and Technology (OART) . The 
Department of Defense (DOD) also served as sponsoring office for certain 
experiments. The experiment's scientific discipline generally determined 
Lhe cognizant SPO. 

Having received and concurred with the scientist’s conceptual 
proposal, the SPO formally presented it to the MSFEB for preliminary 
consideration, and later for final approval. The SPO subsequently 
monitored the scientific and technical integrity of approved experi- 
ments through all program phases to ensure that experiment objectives 
were satisfied, and that adequate funding was provided. 

C. Approval Cycle 

Once an experiment was recommended by the MSFEB for considera- 
tion, an Experiment laqrleraentatioa Plan (EIP) was prepared and a com- 
patibility assessment made. 

1. Experiment Implementation Plan . The PI and the designated 
EDC jointly compiled experiment information in an EIP in as much detail 
as possible. In addition to the experiment objectives, the EIP generally 
included preliminary information for the design, fabrication, test and 
delivery of experiment equipment, and the operating procedures necessary 
to perform the experiment . An experiment development schedule and 
estimated funding (resources) requirements were also included. Experi- 
ment development and delivery schedules as required in the EIP were 
necessarily keyed to overall program-controlled milestones and module 
level development and test schedules. Requirements identified in the 
EIP were concurrently utilized by the Integration Center in performing 
the compatibility assessment. 

2. Compatibility Assessment . This study compared the experi- 
ment’s interface requirements with the program’s existing capabilities 
and constraints. Where incompatibilities were found, solutions or 
alternate designs were proposed that would satisfy the experiment 
objectives without unacceptable impact to the program. At this early 
stage, the compatibility assessment was necessarily less detailed than 
that described in Appendix B, but approached it as nearly as the pre- 
liminary information would permit. Normally, the Integration Center 
conducted this analysis, with support from the PI, the EDC, and the 
operating centers as required. 

3. Final Review and Approval . The experiment proposal, 
supplemented by the EIP and compatibility assessment, was then resub- 
mitted to the MSFEB lor its review and re commend a t ion . The NASA 
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Associate Admin isi lmUh* tor Manned Spam Flight fwho also chaired the 
MSFEB) made t ho iinaL division on approval ol L ho experiment tor im- 
P lemc n t at ion . 

RECOMMENDATION: Emphasise thoroughness in preparation ol 

the EIP and conduct ol the compatibility assessment during 
the iniliai exper iincnL approval cycle, lor early identiti- 
cation of all program impacts and any major problem areas, 

D. Generation of Requirements 

Upon final approval, two types of experiment requirements were 
generated; the design requirements for the scientific instrument 
development and the inter rat ion requirements to support the experiment 
during all phases of the program. The former were stated in a document 
called the End Item Specification (EIS) and the latter were identified 
in an Experiment Requirements Document (ERD). Both of these documents 
vert* the responsibility of the EDO; however, the ERD required EIC and 
operations center support and in some cases was actually prepared by 
the EIC, [NOTE: Occasionally , in the early stages, the descriptive 

portions of the ERD were used as a substitute for the preliminary EIS, 
but this procedure was generally concluded to be less than satisfactory 

RECOMMENDATION: Initiate preparation oi the EIS and ERD as 

soon as possible alter experiment approval. Since the ERD 
is an integration docuinenL , primariU concerned with pro- 
gram-wide interlaces, it should be prepared and maintained 
by tlii' EIC, with supper t and c one u r re nc c i rom t uc E LX. . 
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Upon program approval of tin* experiment , tin* hardware devc Lopment 
proceeded. A st'rios ot roviows was held and tin vv Lopmcn t and qualifies- 
lion tests per termed (see L igu re 4), tu ensure the sat is tact ion ot design 
and inter f ac e r e q u i r e me tus. The s a me s e q u e n c e of r c v \ e ws a nd L e s t s wa s 
imposed on ail experiments regardless of the hardware development status 
when approved for Sky lab* In general, new tests were waived only when 
it could be demons L rated that previous tests had met or exceeded the 
Sky lab requirements . 

Detailed requirements and procedures for the various development 
reviews are described in Appendix C . Appendix D presents a listing of 
specific considerations and constraints pertinent to experiment design. 

An overview of the total experiment testing program is provided in 
Appendix E. 


A. Requirements Baseline 

A formal Preliminary Re q u i r e me n t s Re v i e w ( PRR) wa s co nd uc t e d b y 
the i£DC a I l he earliest practical date alter experiment approval and ED 
selection. The purpose of the PRR was to verity all requirements that 
had to be met to satisfy the experiment objectives, as stated in the 
preliminary E1S and KRD. fhe PRR was intended to establish as a ivquire- 
ment haSvliiu’: a preliminary K1S which properly spec i lied experiment 

requirements in terms et periormanoe criteria and limits; an ER1) which 
properly spec i lied experiment interlace ivqu i rement s on t lie module', crew, 
launch, 1 light and recowry operations; the number ol required end 
items fi.e., flight, backup, test and training units, mock-ups) and their 
schedules; and the development program plan, 

RECOMMENDATION: Involve operations personnel t o help 

ident i fv, assess and resolve the impact s ot operat iona 1 
requirements u pon experiment design (and vice versa) 
at the’ earliest possible stage ot dove lopim nt , to permit 
traeleolis ten* t U e officienu use ot eivv time' ami space- 
e 1 ran capabilities during the* mission. consider tin 
feasibility ol unat t ended ov ’..round -c on t ro 1 led operation 
lor repetitive or L ime -consuming Lum t ions that elo not 
iv quire onboard crow judgment * Minimise e -xperiment 
impacts on concurrent spacccratt act ivit ics. 
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FIGURE 4. EXPERIMENT DEVELOPMENT 
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tlu' Preliminary Design lU-virw (. PDR) ; and the detail design, approved 
at the Critical Design Review (CDR) . 


Development activities leading up t- me FOR were to: 1) accom- 

plish hardware preliminary design (subsystem block diagrams, overall 
dimensions, etc. I. based upon the technical requirements of the base- 
lined EIS; 2) perform trade studies to evaluate alternate concepts lor 
subsystems, consistent with the experiment PRR; 3) perform the develop- 
ment activities that verify new subsystem , manufacturing processes, 
logic design, etc.; 4) define EIS requirements for the GSE ; and 5) prepare 
reliability, quality control, maintainability and safety requirements 
sections for the experiment EIS, 

RECOMMENDATION: Conduct necessary trade studies between 

scientifically desirable and technically achievable 
requirements (e.g., pointing tolerances) as early as 
possible in the development process, to avoid downstream 
incampat ibil ities . 


The PDR was then conducted by the EDC, wherein a design approach 
was selected to proceed to final design of flight hardware. The experi- 
ment PDR objectives were to; l) approve the selected design approach 
tor the flight hardware; 2) evaluate the justification for the design 
approach shown (by trade studies, technical reports, and/or development 
tests’); 3) approve the technical requirements for mock-ups and GSF as 
stated in ELSs tor these articles; 41 review toe adequacy ot preliminaiv 
1 lit , ri ace Cuitr'l Documents (ICDs) provided by the Module Development 
CVnter (see Sect i Ml VI; b> appr 've the verification plan tor the 
selected design; t>l appr >ve produc i b i 1 i ty ol the hardware; and 7) uppi ove 
the completed flight hardware EIS with plans lor quality, reliability, 
s,i I'd v , and maintainability. 


jV.ll aw i iv POR, tin- rX|H‘ t i men t dos i un proceeded ta c ample t i an . 
Final detailed schematics and drawings of all parts were based upon the 
FIS, ICDs, and the approved design approach from the FDR. Appendix D 
lists a number of specific considerations that were recognized in the 
deta i 1 design of Sky lab flight hardware and GSE. 


RECOMMENDATIONS: In addition to the detailed design con- 

siderati'ns rec immended in Appendix D, the following 
general design philosophy criteria are particularly 
emphus i /. i d : 


i Carefully evaluate the eas t -e i f ec t i vencs s '•l using 
rsisting hardware f >r new programs. 
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o Build in safety features (e.g., interlocks, limit 
switches, etc.) to protect the hardware and/or 
enhance serviceability. 

o Standardize crew interface hardware. 

o Emphasize simplicity of operation as a primary design 
objective (e.g., avoid multiple switching operations 
that would permit selection of invalid modes or require 
time delays to preclude logic race conditions). 

o Design manned spaceflight hardware to facilitate 
in-flight maintenance (e.g., provide accessibility 
and suitable workstations with restraint aids for 
crewmen, documents, small parts and tools). 

o Provide telemetry or crew status indicators that give 
direct readout of specific parameters needed for in- 
flight assessment of experiment operation or for 
troubleshooting hardware malfunctions. 

o Ensure existence of capability for in-flight visual 
observation of external experiments. 

During this phase, the qualification and acceptance test 
specifications were prepared, based upon limits in the E1S and pre- 
liminary ICDs. A development (prototype) unit was usually fabricated 
and used for development tests of new design, data system, unusual 
manufacturing processes, etc., and for crew training. 

The design was then reviewed for compatibility with require- 
ments at the experiment CDR„ The CDR results were: baselining of 

the approved detail design of the flight hardware, qualification unit, 
and GSE for release to manufacturing; approval of qualification and 
acceptance test specifications; approval of test and manufacturing 
facilities; and a review of development test results to certify that 
design and manufacturing would involve minimum risk. 

RECOMMENDATION 2 Baselined experiment design should not be 
dependent on unproven advanced state-of-the-art features. 
Resist product improvement type changes after baselining, 
unless they clearly enhance the probability of mission 
success and/or improve cost-effectiveness. 
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C . l-'ab i i ca t 1 a n and Tost 


Lsing drawings approved at CP hi, fabrication acLivi ties began. 

I he number a! hardware units fabricated was a variable, generally 
depending upon the expi-r iiurnt 1 s complexity, schedule and budget. 

In addition to the previ uisly mentioned development prototype and the 
t light unit* there was normally a flight backup unit, a qualification 
test unit and various training units, simulators and mock-ups. (In 
some cases, to minimize cost, it was found acceptable to reuse the 
same hardware for more than one of these applications.) The qualifica- 
tion unit* flight unit, and backup unit or spare parts were all built 
and assembled to the same design drawings, 

REC OMMEND AT ION : Carefully evaluate the need for multiple 

hardware, trading off the apparent cost against the risk 
of needing additional hardware too late in the program 
to produce it without excessive cost or delay. 

At the earliest possible date, the qual i f icat ion unit was fabri- 
cated and subjected to qualification tests, to verify that the design 
was compat ible wi th specified environments. Whenever the qual il icat ion 
unit fail ed a t es t , correct i ve act ion was taken . If this involved a 
tu>w design or a modification to the qua l i f i cat i on unit, it was necessary 
that the new design or modification be incorporated into the Might and 
h ickup units . 

Ihe flight unit was subjected to an acceptance test, usually at 
levels less severe than the qualification test but adequate 1 to verily 
c mi ormance to the design requirements ni the E1S. 

Paring this phase also, the KDC and EP participated in meetings 
with the Integration, Module Development, and Launch Operations Centers 
t > establish the test requirements for pos taccep Lance integration test- 
ing (set* Section V.CK 

RECOMMEND AT l ONS: Supplementing the details in Appendix E, 

the toll owing rec Mimiendat i ons apply t o oxper iment test ing 
in general: 

o Provide experiment hardware and pet I oral testing in 
the logical order ( i . e , , have the deve lopmont 
unit available early in the program, and complete 
development and qualification testing prior to 
flight hardware acceptance^. 
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o Emphasize early identification and timely baselining 
of test and GSE requirements and responsibilities 
preferably as early as PDR. Minimize configuration 
variations in GSE sets to be used for identical tests 
at different test sites, 

o Utilize a team of test/experiment integration specialists 
to develop appropriate integration test plans and 
requirements. 

o Place more reliance on experiment development, quali- 
fication and acceptance test results to reduce 
integrated testing. 

o Consider the cost-effectiveness of using interface 
simulators to minimize interface verification tests 
at the module level, and to preclude premature 
experiment hardware delivery. 

o Support all experiment testing, both preacceptance 
and pos taccep tanca , with cognizant experiment 
development and integration personnel for timely 
problem identification and corrective action. 

n. Acceptance and Delivery 

Following fabrication and test, i Configuration Inspection Re- 
view (CIR) was held to verify that the flight hardware to be accepted by 
the F.DC conformed to the approved design conf igurat ion . Qualification 
and acceptance test results were assessed for validity and conformance 
to requirements. The CIR also verified that the Acceptance Data Package 
(ADP) was complete and that problems which occurred after CDR had 
been properly resolved. The ADP provided a complete set of descrip- 
tive data for each deliverable end item, which was maintained current and 
physically accompanied the hardware when shipped from site to site 
Appendix A includes a full description of the ADP contents. A DD250 
(a NASA form for formal acceptance of the hardware), indicating any 
shortages or open work items to be resolved prior to Flight Readiness 
Review, was approved by the EDC at the completion of the CIR. Pnor to 
shipment from the point of manufacture, a Certificate of Flight Worthi- 
ness (COFW) was prepared and endorsed by the EDC representative (see 
Append ix C). 


RECOMMENDATION 
necessary ADP 
involved , and 
developers . 


: Define a standard list ot minimum 

requirements, acceptable to all centers 
implement it contractually on all hardwa 
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E . Lat c Expe r i men t Add i t i ons 

The value of the Skylab missions was considerably enhanced by 
approval, late in the program, of many new experiments (e.g., the 
Multipurpose Electric Furnace, the Student Experiments, and the Conn: 
Kohoutek Observing Program). To develop these experiments without 
impacting launch dates required an expedited approach to the methodology 
just described. One aspect of this approach was the use of a specialist 
team to prepare major experiment development documentation. Integration 
personnel, already familiar with the interfacing module systems and with 
Skylab documentat ion requirements, were assigned to assist the EDs in 
preparing such documents as the EIS; Failure Mode and Effects Analysis 
( FMEA) ; Hazards Analyses; Operation, Maintenance and Handling (OM&H) 
procedures; Materials List; etc. The results were timely, complete, 
consistent and correctly formatted documents, prepared at minimal cost. 

RECOMMENDATION: Expand upon the Skylab usage of specialist 

teams for preparation of major experiment development docu- 
mentation, tc preclude each developer having to go through 
his own learning cycle. Consider using similar teams for 
experiment-related integration documentation as well. 
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SECTION V. EKPER I ME N T INTECRATION WITH THE MODULE 


Development of the module that carried the experiments proceeded 
in parallel with the experiment development, as indicated in figure 1, 

Hie modules followed a similar pattern of design reviews, fabrication and 
testing. In addition, however, experiment installation and integration 
testing were performed prior to final modttle acceptance and delivery to 
the launch site (see figure 5). 

A* Module Requirements Baseline 

A PRR was conducted by the Module Development Center to baseline 
the technical requirements for the module. The mission and total orbital 
assembly (cluster) requirements were reviewed (e.g., mission orbital 
parameters and durations, module descriptions and interface requirements, 
experiment assignments to modules, control weight allocations, power 
profiles, pointing requirements, natural and induced design environments, 
etc.). [NOTE: As the program progressed, the need was recognized for 

a separate specification identifying these overall system requirements 
imposed at the cluster level. An intercenter Cluster Requirements Speci- 
fication (CRS) was accordingly implemented, and became, in effect, the 
top-level End Item Specification!] Experiment requirements identified 
in the ERDs, current compatibility assessments and integration plans and 
schedules were also reviewed at PRK. These activities, together with 
completion of any PRR action items, established the program requirements 
baseline for the module. 

RECOMMENDATION: Early in any new program (preferably prior 

to module and experiment PKRs) establish and baseline the 
equivalent of the Sky lab Cluster Requirements Specification 
and impose it upon all program elements, to ensure* program- 
wide compat ibi 1 ity with overall requirements (e.g., opera- 
tional environments). At module PRR, formalize the module 
requirements baseline in a preliminary module EIS. 

B. Module Design and Integration 

'The module design anti integration proceeded in parallel with 
the experiment dove lopmor.t ac t iv i t ics (see Sec t ion IV) . Modu le dove 1 op- 
mont activities included: H the basic analysis and design to meet 

module requirements; developing preliminary experiment iCDs tor use 
in the experiments* final design, including definition ot the module 
technical inputs (e.g., dynamic and static loads, number aiui type ot 
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FIG URL 5. LaPURIMLNI INTEGRATION WITH THE MODULE 




electrical connectors, power level, voltages, etc.); 3) a continuing 
compatibility assessment tc show status of design conformance to re- 
quirements and to provide management visibility of problems; 4) pro- 
viding overall module system block diagrams; 3) defining GSE require- 
ments; and 6) establishing subsystem add-ons (batteries, propellant, 
etc.) to satisfy mission requirements. 






A module PDR was held to baseline the preliminary module design 
and the integration approach. The preliminary EIS and block diagrams, 
drawings, matrices, etc., " c each subsystem were reviewed to show con- 
formance to technical requirements of the CRS. The technical adequacy 
of the module design, ICDs, module FMEA, GSE requirements, an updated 
integration plan, schedules and compatibility assessments were also 
reviewed . 

Final module detail design and integration was then started, 
utilizing the PDR baseline. This involved: 1) preparing engineering 

drawings of all parts and assemblies, detail schematics, wiring dia- 
grams , etc.; 2) building of a high-fidelity mock-up of the integrated 
system for review at the CDR; 3) the detail design of all module-provided 
GSE; 4) preparation of manufacturing and assembly plans and drawings; 

5) preparation of qualification and acceptance test specifications; 

6) completion of the module development program (cable layouts, struc- 
tural vibration, etc.) to support final design; and 7) fabrication of 
mechanical interface GSE (provided to some experiment developers prior 
to delivery of flight experiments for verification of interfaces dur- 
ing their acceptance testing). 

The module CDR occurred after the majority of the experiment CDRs . 
Review items included: 1) analyses that suppot Led the ^sign: 2) de- 

tail drawings and plans; 3) the module FMEA; 4) module qualification 
and acceptance test specifications; 5) mock-ups; and 6) ICDs. The 
CDR baselined the final design configuration of the module. 

C . Integration Test Requirements and Procedures 

During the final phase of experiment development, the Module 
Development Center/contractor made preparations for receipt of the 
experiments and for the assembly and testing of the module subassemblies. 

In testing the module, experiment electrical simulators (built by ex- 
periment developers) were sometimes used in place of actual hardware. 

This provided confidence in the design and eliminated many problems 
prior to flight unit delivery. Special Post-Acceptance Test Require- 
ments and Specif ica tions (PAIRS) meetings were held with each EDC/ED 
and the Integration and Launch Operations Centers, to develop experiment 
requirements and criteria inputs Lor the module /oxperimen L integration 
tests and related portions of the integrated systems tests at the launch 
site. The out pul ot these meetings was a coordinated Experiment Integra- 
tion Test Requirements and Specifications (KITRS) document , prepai I bv the 
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Integration Center and concurred with by a L I other centers and contractors 
involved. The Module Development Center then compiled these requirements 
and limits into a Test and Checkout Requirements and Specifications Docu- 
ment (TCRSD) for the module, from which tlie detailed experiment integra- 
tion test procedures- were subsequently prepared by the center responsible 
for conducting the tests . 

RECOMMENDATION: Rase line EITRS documents for the various 

experiments and module TCRSDs (or equivalents) as early 
as possible, and maintain at least the TCRSDs under Level 
II change control, to ensure clear and complete definition 
of integration test requirements for all program elements. 

Maintain uniformity of procedures for performing identical 
tests at different test sites. 

D. Physical Integration, Acceptance and Delivery 

The module now entered the final acceptance phase prior to 
delivery to the launch site. Upon receipt of each experiment at the 
module site, it was subjected to an unpowered receiving and inspection 
test for transportation damage and completeness Of parts and documenta- 
tion. The hardware was then installed in the module, using module 
assembly drawings and the experiment OM&H. A powered functional inter- 
face verification (FIV) test of the experiment with the module was per- 
formed to verify that all electrical and mechanical interfaces conformed 
to the specifications in the TCRSD. Following FIV tests, for all exper- 
iments, a simulated mission test was conducted for the integrated system. 
Some flight crewmen generally participated in this system test as part 
of their crew training. 

RECOMMENDATION: Encourage part icipation in experiment/ 

module integration tests by all flight crewmen who may be 
required to operate the experiment during the mission (s). 

Upon successful completion of all testing, a module CIR y is held. 

The integrated system test results were reviewed to verify that the 
module had met the established requirements. A module DD250 and COFW 
were executed by NASA, and the integrated module was then shipped to the 
launch site. Any experiment or subsystem that was removed for separate 
shipment needed interface reverification at the launch site when it was 
reinstalled. Experiments that were returned to the developer for modi- 
fication or final calibration prior to shipment to the launch site 
required an additional endorsement on their DD250 and COFW by the EDC. 


If flight checklists (see Section VII) were available from the Mission 
Operations Center, these tost procedures followed the checklists as 
c lose ly as possible . 
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RECOMMENDATION: Discourage removal of experiments after 

module integration and acceptance. When this is unavoid- 
able, emphasize critical configuration control and main- 
tenance of appropriate records by all parties involved, 

E. Continuing Compatibility Assessment 

The evolution of the experiment concepts and module designs to 
hardware was supported throughout by a continuing compatibility assess- 
ment, conducted by the Integration Center. This assessment monitored 
the experiment interfaces ~rLth the program for compatibility, proposed 
and coordinated solutions to experiment incompatibility problems, and 
provided management visibility of the experiment integration statu s. 
Further details of this activity are provided in Appendix B. 

RECOMMENDATION: Follow the Sky lab practice of utilizing a 

highly qualified, specialized experiment integration team. 

Assign responsibility for each experiment (or group of 
related experiments, depending upon complexity) to an indi- 
vidual engineer, to act as the single-point source for com- 
piling and disseminating experiment requirements and other 
integration information. Assign responsibility for com- 
patibility of experiments with each carrier system or 
program a jcipline to an individual systems engineer, to 
facilitate experiment liaison with other project groups. 

Conduct continuous compatibility assessment and frequent 
reviews throughout the development and integration phases, 
providing timely management visibility of problem status. 
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Prelatmch and launch activities (see ligure •’ ) were conducted 
hv Ihe Launch Opera! ions (.’enter, with tin- c oy,n i. auci al the Integration 
Center and the support a I the Devi- Lnpiiif.il and Missinii Op. rat inns Centers. 
The peak activity at the launch center obviously occurred alter the 
launch vehicles, nodules and experiments were delivered, but there was 
significant activity prior tn this time tn establish the test and 
facility requirements and test procedures. Tasks performed to identity 
these requirements, as related to experiments, began when the experi- 
ment was approved for the program and continued throughout the develop- 
ment and integration phases. 

A. Launch Center Test Preparations 

Prior to receiving the module hardware, postacceptance test 
requirements, specifications and constraints for each experiment were 
reviewed and approved in a series of formal PATRS meetings, attended 
by representatives from all centers (see Section V.C). following 
these meetings, the Module Development Center compiled the applicable 
module/ experiment Lest requirements, specifications, and criteria 
necessary for preluunch checkout and launch operations into the module 
Test ar.d Checkout Requirements and Specifications Document. 

Similarly, the Integral i m Center prepared a TCRSD for the combined 
integrated systems test. ILsing Lho .creed -upon ICKSD, the launch center 
prepared detailed test plans and procedures lor satisfying these 
requirements, subject to review by the Integration and Development Centers 
The launch Center ,ils- benefited Irani par t i c i pa t i on in the Systems/ 
Operations Compatibility Assessment Review (see Section VI l. A. -). 

B . Receiving and Inspection 

t'pon arrival at the launch center, all hardware (including 
('Si') underwent Receiving and Inspection (K&I). The hardware was 
examined visually tor any damage incurred during shipment. The ADP 
was examined for" completeness ot all documentation and certifications 
required for acceptance bv the launch center. Any available transporta- 
tion environmental information, such as temperature profiles, passive 
accelerometer data, etc., was reviewed to assure that handling and 
shipment constraints had not been vioLaicd. 

experiments that were transported to the launch center 
integrated within the module passed through Receiving and Inspection 
with til. module. experiments shipped separately from the module were 
r.-ceived independently with their >wn Acceptance Data Packages. 



FIGURE 6. P RE LAUNCH INTEGRATION AND LAUNCH OPERATIONS 















Experiments net installed an -module, or actively involved in tests, 
were placed in an environmentally controlled bonded storage area until 
required for use. All GSE underwent a checkout to ensure that 
it functioned properly before being mated to flight hardware. 


C. Prelaunch Integration Tests 


Following R&I, testing at the launch center emphasized system- 
to-system interface verification. Individual experiment testing was 
minimized and consisted mainly of necessary reverification of interfaces 
and final calibrations. 


The activities at the launch center included: 1) the assembly 

and integration of modules to the launch vehicle; 2) verification of 
all instrumentation, communication, environmental , electrical, mechani- 
cal, and structural interfaces; 3) integrated systems tests which 
exercised individual systems as well as combined systems to verify 
overall space vehicle functional compatibility; 4) final Crew Compartment 
Fit and Function (C^F^) checks to assure flight crew members of proper 
hardware integration, accessibility, and safety cons iderat ions ; 3) final 
calibration of experiment sensors; 6) stowage of perishable items; and 
7) securing of all hardware prior to launch. 


D. Design Certification Review 


As part of a final assessment and certification of the design 
of the total mission complex, the Design Cert i f icat ion Reviews (DCR) for 
experiments and modules were held. All involved centers participated 
and the review was conducted by the NASA headquarters Program Office. 

DCR activities began prior to flight hardware shipment to the launch 
center and ended during launch center operations. The purpose of the 
DCR was to examine the exper i ment /module hardware design and the 
design verification programs in order to certify that the overall 
design had met the program objective's tor i light worthiness and flight 
sa fety . 


The following topics were covered at the DCR: 1) an analysis 

of the purpose, design, and interface compatibility of the experiments; 
2) a summary if actions taken as a result of previous experiment 
reviews; 3) a review of safety and reliability cons iderat ions included 
in the hardware design; 4) a review of mission rules and contingency 
plans; : >) an analysis of all prior hardware test programs; and b) the 
status of any remaining open action items. 
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F . Fligh t Read iness Review 


The Flight Readiness Review (FRR) was held at the launch center 
prior to launch. This review assured program management that all aspects 
of the space vehicle, launch vehicle, launch complex, Mission Control 
Center (MCC) , ground instrumentation and networks were ready for flight 
operations. 

The following topics were reviewed at the FRR: 1) the status 

of action items resulting from the DCR; 2) any hardware configuration 
changes that had occurred since the DCR; 3) the current status of pre- 
launch integration testing at the launch center; 4) the status of major 
anomaly reports; 5) a summary of all significant problems that arose 
during testing, and their solutions; and 6) a summary of waivers or 
deviations that had been granted since the DCR, 

j F, Launch Operations 

At the conclusion of the FRR, all testing and stowage was com- 
pleted and attention focused upon final closeout of the entire flight 
vehicle. The launch center was responsible for the launch countdown, 
with the support of the Mission Operations Center. When the flight 
vehicle cleared the launch complex (i.e., umbilical tower), full respon- 
sibility for flight direction reverted to the Mission Operations Center 
(except that the Air Force Range Safety Officer at the launch s ' te 
retained the option of intervening if range safety became endangered). 
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SECTION VLI, MISSION AND RECOVERY OPERATIONS 

Once the launch vehicle was in flight, the entire mission was 
under the direct control of the Mission Operations Center. The pro- 
cedures and techniques used to perform these i unctions had been under 
development and rehearsal since the early phases of the program. 

Figure 7 depicts the premiss Lon preparations and real-time functions 
involved in conducting the mission and recovery operations. 

A. Premiss ion Preparations 

Concurrently with hardware development and integration, 
preparations were made for the operational phase of the mission. 

This activity included the generation of mission and mission support 
documents , reviews of applicable program documentation, crew training, 
and the establ ishment and verification of operational readiness through 
mission simulations. 

1. Documentation Preparation . Using the ERD and module require- 
ments, the Missions Operations Center prepared the basic mission docu- 
ments.* The primary requirements documents were the Mission Requirements 
Document (MRD ) and the Reference Flight Plan (RFP) . The MRD defined 
the requirements and constraints for both the mission and the individual 
experiments. The RFP concerted the MRD information into a detailed 
timeline of crew activities during the mission. These documents were 
utilised during the design and integration phases to show that adequate 
time and systems support would be available to perform the mission. 
Shortly before launch, tile updated RFP became the actual Flight Plan. 

The RFP did not contain the detailed steps for performing a function, 
but was limited to referencing the function (e.g., load film). The 
Mission Operations Center prepared Checklists ter each function (e.g., 
the detailed steps for loading the film), based upon Volume II of the 
OM&li. The Checklists and Flight Plan were launched with the crew 
even though they would be updated during the missioi Other operational 
documents (e . g., Flight Mission Rules, Operational i Books, etc.) were 
prepared to provide further vie: ails; these are described in Appendix A. 

R EC OMM I' ND AT ION: Since Sk v 1 ab prem i ss i on estimates of c r ew 
time required to perform work tasks in the orbital environ- 
ment were not always proven accurate in real time, utilise 
Sky lab mission experience correlations (notably Experiment 
Ml d! , Time and Mot ion Study) l or quant i tat i ve crew task plan - 
n i ng for future missions. 


* Although Data Request Korns (l)RFsf Were also prepared to identify data 
processing requirements during the mission, the discussion of the DRF 
is in Section Kill, Data Processing, Analysis and Reporting. 
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flGURE 7. MISSION AND RECOVERY OPERATIONS 






d 0 0 pi- rations Compatibility Reviews . To assure an iuU'a'aL^, 
approach to mission operations, a series ot Experiment Operations Plan- 
ning (FOP) meetings was convened during the development, and integration 
phases. These meetings brought toother represent at. iws oi experiment 
development and int egrat ion , mission operations, i light p Ian nine ^ PI/ 
users, and various mission support groups Lor the purpose of assuring 
that compatibility existed between experiment objectives and experiment 
operations Documental ion pertaining to experiment operational require- 

ments and techniques was reviewed and compared tor consistency with ex- 
periment objectives. Potential operational conflicts between experiments 
were resolved. 

A more formal program-wide review, the Systems/Operations 
Compatibility Assessment Review (SOCAR) was conducted prior to DCR. 

It consisted of a series of preliminary meetings, similar to EOPs, but 
involving design/development and integration personnel for all Skyiab 
systems, interfacing with the operational personnel at both launch and 
mission operations sites. It culminated in a formal presentation, by 
system, to senior program management. The SOCAR was generally con- 
sidered quite effective in enhancing the program^ operational readi- 


REC0MMENDAT10N: Incorporate the equivalent ot Lhe Skyiab 

SOCAR in the formal program milestone reviews, to be con- 
ducted at Lhe appropriate time to assure maximum coordina- 
tion and subsequent readiness ot tile operat tonal planning. 

J. Crew Training . Maximum cLiiciency during on-orbit opera- 
tions is attained when the flight crev is thorough 1 > familiar with the 
hardware and t lit 1 general objectives. lu this end, the Skyiab 1 light 
crews underwent extensive training, first with high-fidelity mock-ups 
of the experiments and modules provided b\ the hardware developers. 
Later, during integration tests at the module development centers 
(Section V) and at the launch center (Section VI), crewmen wer** used 
in place of technicians for operating the flight hardware at every 
oppor lunit v„ To simulate mission activities, the procedures for those 
tests involving crew par t ic ipat ion utilized the actual flight check- 
lists wherever possible. 

RECOMMENDATION: Follow up any problems or deficiencies 

encountered during crew training, to assure proper reso- 
1 u t i on and i n c o r po r a t i on o f an y resulting ha r d va r e and / o r 
operat ional changes. 


Mi ss ion S initial ions . Prior to launch, a series ot mission 
simulations was periormed, to exercise the t light ana support pe rsornw 1 
in a nalist ic mission environment. For t no purpose ot tin.Sv. sLmuLa- 
tions, the mission was di\ ided into aist in.ci phases, e . g . , lau.ucn, , 
tirst-dav activities, activation, orbital operations, etc. Each 
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simulation was directed at a particular mission phase and covered a 
period ranging from one 24-hour mission day, early in the simulation 
program, to three consecutive 24-hour days as proficiency improved. 

All activities directly involved in mission support were exer- 
cised, in an atmosphere designed to reproduce the actual mission environ- 
ment insofar as possible, even to the extent of introducing hypothetical 
malfunctions and anomalies. Basic coordination, information flow and 
operational procedures were established during these simulations. Fol- 
lowing each simulation, a debriefing was conducted to discuss any opera- 
tional problems uncovered, and corrective procedures were developed to 
preclude their recurrence during the actual mission* 

RECOMMENDATION: Conduct comprehensive prelaunch mission 

simulations, utilizing all applicable communications, data 

links and support personnel* 

B. Mission Control 

Following launch, all phases of the mission were under the con- 
trol of the MCC , located at the Mission Operations Center. This in- 
cluded planning for and operation of all module systems and maneuvers, 
crew activities and experiment operations, from launch through recovery. 
Activities were planned in near-real time on a daily basis, and all 
aspects of mission operations were continuously monitored from the 
ground* 

The Flight Operations Director was responsible for the mission 
operations and provided the management interface between the Flight 
Director and Program Management. The Fiigh- Director, operating from 
the MCC, nad the direct responsibility for mission control. 

The general mission control functions accomplished bv flight 
controllers, with the technical support of other centers and support 
teams, were to monitor and evaluate, in real and near-real time, the 
module systems, instrument systems, scientific data, flight plan activi- 
ty, condition of the flight crew, and trajectory data. Based upon these 
data, decisions were made concerning the progress of the mission toward 
satisfying mission objectives and the Detailed Test Objectives from Lhe 
MRD, and the need for proceeding to alternate flight plans. The flight 
crew was then advised of updated mission instructions and flight plans, 
systems anomalies found during ground monitoring, ground evaluations 
and recommendations to solve or circumvent anv anomalies. 
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Crew Operations /Flight Planning 
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The level of experiment accomplishment is related to the efficiency 
of the crew operations. A prime consideration during flight plan genera- 
tion is the effective utilization of crew time. In any twenty-four-hour 
period, a fixed percentage of time must be devoted to crew personal 
activities such as sleep, meals, exercise, personal hygiene and rest 

periods. The remaining time (approximately ten hours each day was avail- ' 

able on Skylab) is devoted cc experiment operation and, as required, 

systems housekeeping. __ 1 

4 

Each day during the mission., a flight plan was generated by the • 

MCC to cover the following day's activities. This plan, identical in 
format to the premission Flight Plan, was distributed to all mission 
support groups for review and conanent and, after incorporation of approved 
recommendations, the final version was uplinked to the crew via tele- J 

printer before initiation of that day's activities. Specialized inforraa- .■ 

t ion peculiar to that day's flight plan, such as critical times for target 
acquisition, precise exposure times or alterations to the on-board pro- ■* 

cedures checklists, were also uplinked as "preadvisory data" messages | 

(referred to as PADs). The PADs functioned as addenda to the informa- i 

tion stowed on-board in the Flight Data File (flight plan and checklists). j 

D. Mission Operational Support Teams j 

The functioning of the MCC during the missions was backed up by J 

an extensive support organization, both on-site at the Mission Operations 
Center and remote at other MSA centers and contractor facilities. The 
Huntsville Operations Support Center (110SC) was the focal point ot MSIC 

support activities and fulfilled a major role in the conduct of the mission. ] 

Support teams, organized by science/ technical discipline or by spacecraft _ 

system, were composed of representatives from the development and integra- j 

tion centers, contractors and Pis. They monitored the mission progress - 

in real time, and provided the MCC with immediately available expertise i 

r « ative to any experiment or system anomaly that arose. Each lt-am ini- i 

tiated and/or reviewed proposed mission changes to ensure satisfaction of 
the requirements and constraints of their particular area of concern. 

Their basic task was to assure the optimum success of their experiments 
in the face of whatever off-nominal conditions might occur during the 

mission. The primary areas of team concern were: 1) continual planning of 1 

future activity necessary to achieve maximum experiment success with relation i 

to all other mission parameters, and 2) rapid and accurate response to any 

in-flight anomaly, either vehicle r experiment-related, to maximize the i 

experiment data returned under the prevailing conditions. In connection 

with the flight planning activity, the Skylab experiment support teams \ 

made regular inputs to the "Science Planning Meetings," conducted twice 1 



wek iy bv t ho Program Scientist at t he Mission Operations Center, which 
proved to be an etL'eetive means tor influencing the MCC tllghl planning. 

RECOMMENDATIONS: The primary recommendations resulting 

from Skviab experiment mission support experience were: 

o Utilize personnel for mission support who have 
participated in experiment development and/or 
integration and have experience with hardware* 
related problems. Ready availability of the Pis 
or their authorized representatives is highly 
desirable, particularly for the more complex 
experiments. 

o Frovide near -continuous cowaunicatlon between space- 
craft and SCC, more direct communication and data 
links between MCC and the mission support teams, 
and fewer intermediaries between the teams and the 
flight crew during anomaly troubleshooting. Also, 
limited but frequent direct communications between 
the flight crew and the Pis are both feasible and 
productive. 

o Provide mission support teams with available experi- 
ment hardware to permit realistic ground simulation, 
taeilitat ing real- t imo t rouhloshoot mg. 

o Utilize Lraincr walk-throughs by ground-based 

astronauts to check out lute add it ions and real- 
t ime procedural changes before t ransmit t ing them 
to the crew. 

o Emphasize active participation of experiment 

mi s s ion support t e ams in L n f 1 ue nc i. n g p r e par a t ion 
of daily t light plans by maintaining liaison with 
the MCC flight planners and supporting semiweekly 
sc ioneo planning meetings . 

E. Recovery Operat ions 

Operations at the recovery site were planned to ensure that 
the integrity oL physically returned experiment data f primarily 
photographic tilm and specimens) was not compromised and that pre- 
scribed handling and delivery requirements were satisfied. These 
requirement s * a long wi. t h any app 1 i cub le s upper t t unc t i ons , had been 
identified early in the program. Preliminary recovery site require- 
ments tor each experiment were ideniitivd in the original ERDs , and 
speciiic handling procedures vv rr later detined by means ot DHFs. 
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These forms were used to detail temperature and humidity limits to be 
observed, shielding requirements if applicable, special containers 
required to protect the data, or other handling techniques necessary 
to isolate the material from the external environment. 

Following retrieval of the crew and spacecraft, recovery site 
operations included deactivating potentially hazardous systems and 
securing the module subsystems; initiation of ground support functions | 

such as purges, thermal conditioning, ground power, etc.; and the - 9 

retrieval of experiment and subsystems flight data. The returned data 

were removed and packaged for transportation to the data distribution rfl 

center and subsequent processing and/or dissemination to the Pis and ■ 

data users . m 





SECTION VIII 0 DATA PROCESSING^ ANALYSIS AND REPORTING 


Data requirements of the experiment Principal Investigator or 
data user were initially stated in ERDs and subsequently amplified in 
DBFs. Using these requirements, the Mission Operations Center developed 
the plans and software required to retrieve, process and distribute all 
flight data* The development centers were responsible for the Mission 
Evaluation Reports, and the Principal Investigator or data user was 
responsible for scientific data analyses and reporting of results* 

Figure 8 shows the functional flow for this phase* 

RECOMMENDATION : Clearly define the respective 

responsibilities of NASA and the participating 
scientists in the following areas: 
o Funding 

Data retrieval, processing and delivery 
Systems performance data required 
Proprietary rights ^ data 
Reporting requirements 

Data security, accountability and archiving 
Involvement in Public Affairs Office activities. 

This was accomplished iate in the Skvlab Program by 
implementation of the Experiment Scientific Data 
Analysis and Reporting Documents (ESDARDs) . 


o 

o 

o 

o 

o 

o 


t 'i 
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A. Premission Preparations 

During the premission phase, arrangements were made for the 
acquisition of data pertinent to experiment success. The initial 
requirements were stated in the ERDs. The DRF was later employed as 
the formal method of requesting data for all users. The data required 
for the scientific invest igat ions was defined by the PL/user, docu- 
mented on DRFs, and submitted to a data requirements group at the 
Mission Operations Center for approval, processing and implementation. 
The DRFs specified the data recipient, the pertinent data required, the 
specific times during the mission when the data was to be acquired, 
desired format, and the date when the data was needed. 


Based upon the DRFs, the Mission Operations Center prepared 
software programs lor general processing oi the flight data. Further 
(more detailed) processing, required by certain experiments, was 
provided by the cognizant EDC . Available programs were exercised 
during the mission simulations, using recorded data generated during 
the integration tests. 
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DATA PROCESSING, ANALYSIS AND REPORTING 



ppp 




RECOMMENDATION: Skylab data processing and analysis 

proved to be far more complex and time-consuming 
(and therefore more costly) than anticipated, indi- 
cating the need for more emphasis on premission 
rehearsals of the entire sequence, In order to op- 
timize the operations, shorten data retrieval time, 
and determine realistic time and cost requirements 
for these activities. 

B. Flight Data Processing 

Flight data was received and catalogued at the Mission Opera- j «| 

tions Center both during and after the mission. Returned flight f I 

samples were released to the PI for examination and analysis. Opera- I ;j 

tionai film and much of the scientific film were processed by the f |l 

Mission Operations Center and duplicates distributed to the data f g 

users. In special cases, scientific films were delivered to the Pis 
for processing and analysis, with the understanding that the original 
flight film and a reproducible master were to be returned to archives 
at the completion of the analysis. Recorded and telemetry data were 
processed through appropriate software programs and reduced to com- 
puter-compatible tapes prior to release to the data users. Other 
requested data formats included: tabular forms, strip charts, micro- 

film, transcripts, video tapes and digital television displays. 

C. Data Accountability 


The PI was normally granted proprietary use of the returned 
scientific data for a one-year period alter all requested data was 
delivered to him. he was responsible lor the physical security and 
integrity of all mission data received by him while it was in his 
possession. He was required to take proper action to prevent loss, 
theft or unauthorized use of this material (refer to MSEC Management 
Instruction 4010.2). At the conclusion of this period, all orbital 
material was required to be returned to the EDC archives. TherealLct, 
NASA retained control of the returned material lor possible further 
scientific investigations. 

D. Scientific Data Reporting 


A PI was normally granted initial publication rights to 
experiment data for a period of one year. Each PI was responsible 
for generating periodic reports of I) is investigative findings at 
intervals of 30 days, 90 days, 6 months and i year alter splashdown. 
Normally, within the 1-year period, the PI was to deliver a t inal 
r, port of his experiment results lor publication. [NOTE: Tin. Pi's 

proprietary and publication rights, indicated above , will in no was 
preclude government access to and use ot data tor mission analysis, 
troubleshooting, or other oliieial purposes^ 
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E. Mission Evaluation Reports 

The cognizant NASA centers were required to prepare Systems 
Mission Evaluation Reports within six months following mission comple- 
tion. These reports (see References 6 and 7) contained performance 
evaluations of experiment and systems hardware for which the reporting 
NASA center had development responsibility, and also assessed the 
degree to which operational constraints and interface requirements had 
been met during the mission. They did not attempt to evaluate the 
scientific significance of experiment data. 

F. Final Technical Reports 

Concurrently with preparation of the Mission Evaluation Reports, 
the E1C prepared a final technical report (Reference 8>, tracing the 
evolution of Skylab corollary experiment development and integration 
froui the t-i»1 experiment co ncept s through mission operations . Simi- 
lar final technical reports were produced for the Apollo Telescope 
Mount experiments (Reference 9) and for each Sky lab nodule. 




SECTION IX. CONF 1GURAT ION MANAGEMENT 



f 


The configuration management system provided a control cycle 
for systematic evaluation, coordination and approval or disapproval of 
all proposed changes to baselined specifications, hardware or systems, 
to ensure that all involved organizations were working to common con- 
figuration baselines. Early identification, timely baselining, and 
accurate, up-to-date maintenance of the hardware configuration status 
and related design mid operational documentation are essential to 
effective program management, if for no other reason than to minimize 
changes. The application of refined configuration management methods 
and controls contributed to the successful Integration of Skylab. 

RECOMMENDATIONS: Configuration management can be 

made more straightforward (and thus less costly) if the 
following documentation ground rules are adhered to: 


o Establish a clear-cut, nonredundant documentation 
tree early in the program, and enforce ii on all 
program elements* 

o Definitive information should appear in only one 
document, and each document should be tailored 
to suit its purpose, omitting nonpertinent or 
redundant informat ion • 

o Impose prog ram -wide standard i ormats t or major 
document types, such as ELS and ERD. 

o Baseline documents prior to initiation of activi- 
ties that require their guidance. 

o Formally delete documents (or sections thereof) 
from the program as soon as their pin pose has 
been served. 

A. Configuration Control. Organization 

The primarv organizat ions responsi hie for the Skylab coni iuura- 
t i on control system were; 

L . Coni Lguraiion Control Boards . flu CCS was a primary t mu i W 
of the sys toms engineering activity and included representatives i rom 
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ti u - various pro ject oil ices and technical svstems disciplines as appro- 
pr iat c . Control ot the mam ini ri\ lot v d JiieummU s (_s<.'C Appomlix A./ vas 
ac c omp L ished on a mu It i Low 1 basis; 

Tho Level I CCB approved changes to the base Lined overall pro- 
gram requirements, including program objectives, experiment ass ignment s , 
major schedule milestones, and budget allocations. Approval authority 
rested with the NASA Headquarters Program Director. The Level 1 CCB 
also acted to resolve any matters referred to it by the Level II CCB. 

The Level II CCB approved changes to baselined requirement or 
configuration documentation which would impact two or more centers (or 
two or more project offices within a single center)# Approval authority 
rested with the center -"level Program Managers* All affected projects 
and centers evaluated proposed changes for impacts to their respective 
areas of responsibility, prior to Level II CCB action. This ensured 
that the total impact of a proposed change was fully understood, tech- 
nically assessed, and compatible with established requirements , costs 
ami schedules. If a change affected primary miss .on objectives, experi- 
ment assignments, authorized funding, or major program milestones, the 
Level II CCB could either disapprove the change or refer it to the Level 
I CCB for disposition. 

The Level III CCB approved changes to baseline requirement or 
cent igurat ion document at ion af feeling a single project office within 
the jurisdiction of a single center. Approval authority rested with 
t aeh Project Manager responsible for development ot a major module oi 
group ot experiments. 

The Level IV boards, often iniornulh at a hardware contractor's 
lac i Lit y, controlled d i sere i ionary internal changes not at tec ting put a- 
me t e r s controlled at 1 \ L g h e i levels. 

2. Change Integration Korkin;.; Croup jClWC) . Ihe ulLu included 
representatives oi the various technical systems disciplines auO systems 
engineering and integration, and performed a screening i. unction tor Lite 
CCBs throughout the premission phase of the program. This group proved 
to be a primary tool for ensuring that the early design was well coor- 
dinated . 


3. Configuration Change Integration . A coni igurat ion management 
support group was established at each involved center to maintain an up- 
to-date status of interfacing hardware and document at ion and to process 
requested changes. This group coordinated all proposed changes to en- 
sure that the interests ol all interfacing organizations had twei con- 
sidered. Tins tune l ion was ret erred to as coni igurat ion han-.n i-\h- 
gration. It included receipt ot proposed ciunns. coordination wit:- 
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all affected organizations to determine total impact of the change 
(including cost and schedule) , submittal to the appropriate CCB for 
action, and maintenance of overall configuration status. 


B. Configuration Control Operation 


Changes to documentation and to hardware prior to baselining 
were controlled initially by the originator or the hardware developer. 
Once baselined, full configuration change control was implemented. 

The proper intercenter experiment change process is illustrated in 
figure 9. 

necessary changes were identified in various ways: by con* 

tinning compatibility assessment of the related documents, by the 
respective hardware milestone review* during hardware development * 
testing and manufacture* or by the addition or deletion of experiments 
during the program, The changes were generally initiated either by 
the hardware developer or by the Integration Center support groups. 

If initiated by the hardware developer* an Engineering Change Proposal 
(ECP) was prepared to define the change and its impact to the hardware, 
systems, specifications, interface documents, cost and schedule. The 
preliminary ECP was submitted to CIWG by the originator, and was re- 
viewed for impact on program documentation by the compatibility analysis 
support group, and technically coordinated with the affected Pis 
and others as necessary. If incompatibilities were identified, an 
Engineering Change Request (ECR) and supporting change documentation 
were prepared. The ECR was an adaptation of the ECP for use primarily 
with program documents and specifications. The ECP, ECR and supporting 
documents formed a total package which presented all the change impacts 
for CCB evaluation. The approval, approval with changes, or disapproval 
by the CCB chairman was implemented by a Configuration Control Board 
Directive (CCBD). 

Changes were also initiated by the Integration Center (through 
the support groups) when incompatibilities were identified. In tills 
event, the ECR was prepared and submitted to the CIWG for subsequent 
CCB action. The hardware developer received and analyzed the ECR for 
impact and, if an impact was identified, prepared an ECP to define it. 
The ECP and the ECR were then processed by the CCB, as above. 

The CCBD resulted in the preparation of Change Orders or Supple- 
mental Agreements for transmittal to the affected cont rac tor (s) or Pro* 
ject Offices, directing the incorporation of the change into the docu- 
ments and hardware. Document changes were incorporated and distributed 
bv the document custodians. 
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It is essential that any change proposal identify all the 
hardware and documentation (at the same or other levels) which may be 
affected thereby. Accordingly, when a change was initiated from any 
source , the Integration Center formally conducted a change impact 
assessment. This assessment identified impacts to all interfacing 
hardware and documentation that might be affected. A checklist was 
used to identify the areas to be investigated. The changes were 
precoordinated with alL affected organizations by the Integration 
Center before the CCB meeting. Thus the Integration Center was able 
to prepare a complete and coordinated change package for assessment 
at the CCB meeting. The Integration Center was uniquely qualified 
to perform this function and, by so doing, assured completeness and 
consistency of format and relieved other affected organizations of 
the need to expend resources to perform this task. Use of this 
technique greatly expedited CCB control of experiment -re la ted changes 
at MSFC during the later stages of the Skylab Program. 


RECOMMENDATION : Utilize the "Complete Change Package" 

concept and precoordinate change packages with all 
appropriate disciplines prior to presentation to the 
CCB. NOTE: Configuration control cannot wait for 

each organization to finalize its document changes 
before acting on a proposal. The CCB Directive 
documenting a decision will specify any modifications 
to tiie change proposal that are considered necessary 
bv the CCB. Document update pages implementing the 
CCB direction can Lhen be prepared and distributed 
by the responsible organizations. 


D. Configuration Control Milestones 


Configuration control closely followed the hard ware development 
milestones. Following the PR R for each experiment and module, the re- 
quirements documents were baselined and thus came under CCB control 
for changes. After PDR the documents that defined the approved design 
approach were controlled by the CCB. Likewise, following CDR, the 
approved detail design and test specif icat ions came under CCB control. 


When two or more development activities took place in parallel 
(such as experiment and module development) there were three key Level 
II CCB functions that permitted these activities to proceed smoothly. 
The first occurred following the development PRRs , when the LRDs were 
placed under Level II control, own thouudi they nad been baselined 
previous 1\' at Level III. This allowed assurances to hot :i developers 
Lhat their chsign approaches were based on firm requirements, i.e.. 
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that changes to interface requirements would be minimised and necess.'., ' 
changes identified to alL eoneerned. The second tune lion occurred 
during the design period prior to PDR, when the ICDs prepared by the 
module center had Lo be coordinated with the LDC to er.sute mutual 
agreement on the interlace details. These preliminary ICDs were then 
baselined at PDR, at which time they came under Level II control. 

K it ti Level 11 ICDs, Lite developers could continue their detail designs 
with assurance of having iirm interlace agreements. The thitd majoi 
CCB function at Level II was control ol the TCRSDs, which allowed the 
Module Development and Launch Operations Centers to prepare their 
detailed test procedures for testing the integrated systems. 







SECTION X. SPECIAL DISCIPLINES 





Requirements established by specification for safety, reli- 
ability, maintainability and quality assurance affected all phases 
of the program ard were necessary to assure mission success. Inter- 
related with these requirements, specific attention was focused on 
crew systems (i.e, , man/systems integration, or "human engineering 11 ) , 
materials compatibility, contamination control, and various other 
systems -oriented disciplines . The impacts of these special disci- 
plines upon an individual experiment were influenced to some extent 
by the criticality of that experiment's potential failures. 

Experiments were categorized in the EIS according to the 
criticality (severity) of potential effects that could be produced 
by their worst-case failure modes. Criticality category identifica- 
tions varied between centers, but were generally consistent with the 
following basic definitions: 

Category 1 (or I) - Adversely affects personnel safety 
(flight or ground). 

Category 2 (or II) - Causes loss of a primary mission 
objective but does not adversely aff ct personnel 
safety (includes unscheduled termination of launch or 
mission) . 


Category 3 (or IIIA) - May cause loss of a secondary 
mission objective but does not ad verse 1 y a i 1 e c t pe r - 
sonne 1 safe tv or preclude- the achievement oi a primary 
mission objective. 

Category 4 (or IIIB) - None of the above, generally 
applicable to relatively passive experiments with 
very simple interfaces. 

RECOMMENDATION: Standardize criticality category 

and sub -category designations to be used by all 
program elements. 

The criticality category influenced the scope ot the s ety, 
reliability , quality assurance and test programs at Liu experiment, 
module and overall program levels. Increased santy margins, 
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special design features, increased inspections during fabrication 
and assembly, and special tests to ensure existence of adquate mar- 
gins are examples of cons iderations given to experiments that had 
high-risk failure modes. The worst-case classification was applied 
without regard to probability of occurrence. 

A. Safety 

To ensure that hazards were identified and resolved throughout 
the program, the development centers required formal or informal im- 
plementation of safety program requirements for each end item. This 
program assured that methods were adequately implemented for identifi- 
cation and either elimination or control of potential hardware hazards 
that could result in injury to personnel or damage or loss of flight 
or ground hardware. Hazard Analyses were performed to identify, and 
offer solutions for, hazards that could result from failures, normal 
or emergency equipment operations, environments, personnel errors, 
or design characteristics. A "System Safety Checklist” (Reference 10), 
containing specific design criteria applicable to flight and ground 
hardware, has been developed to assist new programs in the appli- 
cation of safety-related experience. 

B. Reliability 

Integral to the design and development process was the evalua- 
tion of hardware reliability through analysis, review and assessment. 

A Reliability Plan was prepared for each end item, describing how the 
reliability requirements were to be implemented and controlled. 

Hardware failure modes were defined in FMEAs . Based on the results 
oi the FMEAs, a Critic- T temr Li.d (OIL) was prepared, which included 
a summary of single failure points and critical redundant (backup) com- 
ponents in life- or mission- oss'-uit i al equipment. In addition, design 
criteria were provided for the reliability of each subsystem. Reliability 
testing per se was generally not done; however, in certain very critical 
cases, some lifetime testing was conducted. After the hardware was 
fabricated, a system of providing information on unsatisfactory condi- 
t i ms or anomalies was utilized to keep abreast of reliability goals. 

C. Mainta inability 

The requirements for maintainability are closely associated 
with reliability and safety requirements during ail program phases, 
with the major effort concentrated in the design phase. The princi- 
pal elements of maintainability assurance are: l) provide design 

parameters (e.g., mean-t ime-to-repair , fault detection and isolation, 
limited lifetime items); 2) analysis of design; 3) design review 
participation; 4) data on maintainability; and 5) verification and 
demonstration of the maintainability. 
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To the ext e n t p r ac t i c a b L o , exp e r ime u t s wo r o d e s i gn od i o r 
accessibility, rep Laceabil ity and serviceability during ground opera- 
tions. Sky lab's original design philosophy speciiically minimised 
in-f light maintenance as a design consideration. The rationale tor 
this decision was quite logical in the circumstances. Inadequate 
data existed at that time on the astronauts' ability to perform com- 
plex tasks in space, or on the crew time, workshop space and weight 
budget that would be available. Thus extensive reliance upon in- 
flight maintenance, rather than designing for high inherent relia- 
bility, would have involved high risk. Actually, as the program 
matured, some minimal in-flight maintenance provisions were found to 
be essential, and were added. During the actual missions, however, 
in coping with unforeseen anomalies, the astronauts demonstrated 
excellent capabilities in this respect, even with improvised tools 
and in extravehicular activity (EVA). 

RECOMMENDATION : Design future inarmed space hardware 

to permit a much greater degree of in-flight mainte- 
nance, including EVA. Provide appropriate on-board 
spares, crew training and supporting documentation 
for maintenance tasks. 

D. Quality Assurance 

A Quality Assurance Program was implemented to ensure that 
all necessary actions were taken to provide confidence that the 
experiment would perform satisfactorily during flight. The quality 
prog*-*'^ provided methods for detecting, documenting and analyzing 
deficiencies, system incompatibilities, or trends that could have 
led to any unsatisfactory quality of the experiment hardware. 

At all sites (development, integration, launch, mission 
operations), a general method was used for reporting ail anomalies 
(failures and unsatisfactory conditions) relating to flight, test, 
simulator or training hardware. The reports identified the anomaly, 
where it had occurred, and the corrective action required. All 
participants (quality, engineering, test, NASA, etc.) concurred in 
the corrective action by signature. Within this formal method of 
tracking anomalies and recording their solutions, quality assurance 
personnel were responsible for verifying that the anomaly occurred 
as stated and that corrective action requirements were adhered to. 

A Failure Analysis was performed, where necessary, to determine the 
cause of the anomaly and identify adequate measures that could be 
implemented to prevent its recurrence. A status was maintained on 
all open anomalies until they were satisfactorily resolved. 
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Stroll;.', omp'nus i s in t in' design, t U\ c Lopment and ini cgrat ion. ot 
SU\ lab experiments and moJuUs was placed upon inan/sysl cms integration 
and human engineering, to onsuro clticicnl utiliration ot t ho ground 
and t L i ;.;h t crows' capah i L i i ios in the applicable c m i ronmen t s . fUm/ 
system design criteria wore established Lor ready accessibility and 
identification, convenient arrangement, and ease oi operation of ex- 
periments and cluster systems equipment. General cluster habitability, 
fixed and portable illumination, controls and displays, mobility aids 
and restraints, stowage, and provisions for extravehicular activities 
received particular attention* 


High-fidelity mock-ups and/or training hardware were utilized 
to conduct numerous formal reviews and informal walk-throughs by 
astronauts, Pis, and integral ion^personncl during the deveiejuaent 
and integration phases. The C 2 F- tests were conducted on t light hard- 
ware as a part of acceptance tests and prelaunch checkout. Walk- 
throughs were also extensively -ised during the missions to check out 
new or revised operational procedures before transmitting them to the 
L light crew. Extraordinary activities involving EVA (e.g., deployment 
of a damaged solar panel) were rehearsed in the MSFC Neutral Buoyancy 
S imulai or * 


Post i 1 Li;hL evaluation ot Sky lab crew systems hardware is dotu- 
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F . Mat er t a Is Program 


and 


von - ro LI i nr, materials selection, test 
evaluation required that each Development Center Program Ot • ice prepare 
an implement ai ion plan and identity an i nd i v idual materials specialist 
to serve as local point tor 


tin' venter s 


materials program. Lnurventv 
coordination was accomplished bv a materials intercenter working group, 
which exchanged pertinent informal ion , test data and deviations, and 
reconciled diliercnces between the centers. Hardware developers woic 
required to submit appropriate materials and parts lists, under their 
rvspvv t i vo Rc 1 iab i l i t v Plans . 
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Skv lab materials program placed particular empnasis on 
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important materials characteristics assessed wore toxicity, odor, 
out gas sing, offgassing, and flaking or powdering tendencies of paints 
and coatings. Materials information and test data provided signifi- 
cant inputs to the in-flight contaminat ion control program. 

These activities on Skylab resulted in the preparation and 
release of a new OMSF material evaluation criteria document, 

NHB 8060.1. Although released too late for formal implementation on 
Skylab, NHB 8060.1 is understood to be a requirement for current OMSF 
programs. 

i is 

G. Contamination Control j 

Hardware cleanliness monitoring prior to launch is a quality ;f 

assurance function, amply covered by specifications and conventional I 

j quality control methods imposed on Skylab. However, analysis and :’| 

i control of the contamination that can occur in and around an orbiting 

spacecraft emerged as an important new discipline that warranted 
status approaching that of a major functional system. In-flight con- 
tamination, internal or external to the spacecraft, presented potential 
problems for nearly all experiments and cluster systems, notably those 
involving critical optics or other operational surfaces. 

A Contamination Control Working Group, including 
representation from MSFC, JSC, KSC, the Pis and contractors, was 
established at the Integration Center to conduct, coordinate and 
manage these efforts. Potential contamination sources were identified 
and quantitatively defined with the help of extensive materials testing. 

Experiment and system sensitivities to contamination were determined. 

Rigorous analyses, supplemented by comprehensive systems ground test- 
ing, were conducted to develop mathematical models of the performance 
of the sources and thereby predict in-flight contamination levels . 

Recommendations were made for design and operational procedure 
criteria and changes to minimize contamination effects (e.g., proper 
timelining of experiment exposure or operation in relation to various 
sources such as reaction control system firings and overboard venting). 

Instrumentation was flown, such as quartz-crystal microbalances to 
monitor mass deposition rates and cloud brightness monitors for the 
induced atmosphere around the spacecraft. Flight data from these 
monitors and from certain experiments was used to validate and improve 
the prediction models’ accuracy. The major sources of in-flight con- 
tamination, as predicted, were materials outgassing and reaction 
control system firings. The total Skylab experience clearly demon- 
strated the necessity for , and l he validity of , these measures . 
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RhCOMMLNDA i IONS : ImpK a ;iL rigorous and comprehensive 

measures tor in-t light contamination control earlv in 
any new program, particularly where optical experiments 
are involved. Integrate the degradation effects of all 
contributory systems into the program design criteria 
on a level comparable to the major functional systems. 
Investigate new techniques for in-flight cleaning of 
accessible and remote optics. 

H. Other Special Disciplines 

Various other Sky lab systems engineering activities influenced 
experiment development and integration* 

Electromagnetic Compatibility . An inter center/contractor 
Electromagnetic Compatibility (EMC) Working Group monitor ed compliance 
with the Skylab requirement that hardware be free of adverse electro- 
magnetic interference (EMI) under operational conditions. EMC 
compliance was established during the design phase and demonstrated 
predominantly by component-level testing, where circuit analysis was 
not considered adequate. A minimum of EMC testing was conducted at 
the module level to confirm the lower-level results. The' EMC Working 
Group reviewed all pertinent designs, analyses, tests and waivers. 

No major EMI problems were encountered during the Skylab missions. 

2* Corona Suppression . A management -supported , program-wide 
effort to emphasize corona prevention was the key to success in this 
area. Corona specialists conducted frequent reviews of designs and test 
plans with their originators. This effort proved sufficient to minimize 
the degree of testing required and the rework of test failures that 
occurred, while maximizing the assurances gained. No serious loss 
of data or system failure due to corona effects occurred during the 
Skylab missions* 


3. Sneak Circuit Analysis . A sneak circuit analysis was 
performed on the integrated electrical systems to assure a low proba- 
bility of undesired current paths. A computer was used to help 
develop a simplified schematic of Skylab circuits for evaluation. 

This analysis verified electrical interfaces and provided valuable 
source material for checking operational documentation and for 
investigating real-time operational anomalies and workarounds. 

Ihe program was successful in identifying 44 sneak circuits, plus 
a number of unnecessary components and documentation errors. 
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SECTION XI. PUBLIC RELATIONS 




! 


I 


Public awareness of program objectives, progress and benefits 
is an important obligation for NASA, which must be shared by the 
scientific investigator. Different approaches for public relations 
were required for the various experiments, depending upon an experi- 
ment's public appeal, the public's awareness of the Principal Investi- 
gator, and their ability to comprehend the science and potential 
applications of the experiment. 

A. NASA Public Affairs 

Each NASA center maintains a Public Affairs Office (PAD), With 
established contacts for releasing space-oriented news to the media. 
Standard public affairs releases, consisting of NASA photographs with 
captions and prepared news stories, were released to the national news 
services. These releases normally contained only general background 
experiment information. 

Press conferences which required the Pi's participation were 
arranged periodically. They were generally scheduled for periods of 
peak public interest in the experiments (e.g., immediately prior to 
launch, following experiment performance or return of flight data, 
or to present results of flight data analysis). These briefings 
were held where the space -oriented press was gathered; at the launch 
center for launch, and at the operations center during mission opera- 
tions. Often a press conference presentation led to a private inter- 
view with a newspaper, periodical, or news service reporter. 

The press is primarily interested in results which can easily 
be understood by the public, i.e., the "biggest", the "best", or the 
"first." It was extremely helpful when the PI played an active role 
in releasing photographs of returned data with lucid explanations of 
the observable scientific phenomena. Scientific analysis was not 
required, or even desirable, in these press releases; simply a state- 
ment of what occurred and its potential significance. The objective 
of press briefings and press releases is to achieve public awareness, 
rather than public education. An active interplay or established 
liaison with the PAO assured the PI that accurate experiment informa- 
tion was being released, while the PAO was guaranteed interesting, 
newsworthy releases . 

RECOMMENDATION: Statements tor public release should 

not be issued without prior program approval . 


1 
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B. Educational Programs 




Various educational programs initiated by NASA may require 
par t icipation by the PI and/or experiment development or integration 
personnel. The following educational aids can be produced by NASA 
with limited participation required from these personnel. 

o Film Clips - Ten-minute motion pictures can be filmed 
of the PI explaining and demonstrating his experiment 
and the application of its results. These films are 
useful in providing program personnel with a more 
thorough understanding of the experiments* or as pres- 
entations demonstrating the state-of-the-art of space 
research to science students* 

o Educat ional Mds-Scieaceeducatianal aids can be 
prepared to describe groups of experiments , the appli- 
cation of basic principles of science and physics to 
execute the experiments, and the scientific value of 
the results. 

o Displays - Visitor center or museum-type displays can 
be distributed to visually stimulate the public* s 
interest in space technology. 

o Postmission Historical Texts - Books printed after 
mission completion, with extensive use of mission and 
experiment photographs, can provide an informative, 
nontechnical presentation of mission/experiment oper- 
ations and results. 

Many different types of documents and presentations may be 
produced for educational purposes. These are the principal ones 
which will require a degree of cooperation and information from 
experiment personnel. 
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DOCUMENTATION 






Tliu principal experiment-related development, integration and 
mission operations documents required and utilized on the Skylab pro- 
gram are described in this Appendix. A documentation tree illustrating 
their primary interrelationships is shown in figure A-l. All documents 
were subordinate to the OMSF Skylab Program Specification, SE 140-001-1, 
which was the top-level technical specification for major program func- 
tional and performance requirements. 


A. Experiment Development Documentation 


Ihe approved Experiment Implementation Plan (EIP) , as described 
in Section III.C.l, provided the initial experiment definition, from 
which formal development documentation was derived. 


An OMSF "Experiment General Specification for Hardware Develop- 
ment" (EGS) identified requirements to be selectively imposed upon ex- 
periment developers, at the discretion of the Experiment Development 
Center. Considerable flexibility was permitted in EGS implementation 
(depending upon the experiment's complexity and criticality) to mini- 
mize development costs within the constraints of crew safety and mis- 
sion success. As an EDC, JSC imposed its own "Experiment Hardware 
General Requirements Document" (EIIGRD) , which generally paralleled EGS 
requirements but differed in some significant details. Specific devel- 
opment documentation requirements identified in these two specifications 
were similar, except as otherwise noted herein. 


RECOMMENDATION: Establish and maintain uniformity 

oL requirements among diverse experiment developers 
by selective implementation of a single coordinated 
general requirements specification across all pro- 
gram elements. 


Development documents were categorized by the cognizant EDC 
as: Type 1, to be submitted for approval; Type II, to be submitted 

for review; or Type III, required to be available upon request, but 
not formally submitted. The Type 1 category was generally limited 
to documents that defined and/or controlled major elements of program 
cost, schedule, or performance. 

^ • Management Plan . At Liu outset ol the development effort, 
a Management Plan was prepared by the ED for EDC approval, defining, 
toe management organization and procedures to lie used during develop- 
ment ot tin experiment hardware and GSE. It defined the responsibilities 
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and controls to bt' established and maintained throughout an integrated 
development effort, covering all hardware and GSE for which the developer 
vus responsible, ihe plan contained the following sections! 

o General Management - defining the management structure, 
responsibilities and controls for the overall 
development effort 

o Quality Assurance - defining a Quality Program Plan 
and a Contamination Control Plan 
o Reliability Plan 
o Configuration Management Plan 
o Test Management Plan 
o Logistics Support Plan 
o Manufacturing Plan 

o Development Schedule - defining detailed schedules for 
the design, manufacturing and test efforts, includ- 
ing all related configuration management reviews, 
documentation and hardware deliveries 
o Nonmetallic Materials Plan (EHGRD only) 
o System Safety Plan (EHGRD only) 

2 . Configuration Management Documents 

a. End Item Specification. The ED was required to pre- 
pare and maintain a detailed End Item Specification (EIS) for each 
type of experiment hardware identified in his Statement of Work (i.e., 
flight, mock-up and training hardware, and GSE). The EIS contained 
the Lotal requirements for the development program and formed the 
technical basis for the contract between the ED and EDC . Specifica- 
tions were prepared on a paragraph-by - paragraph deviation basis to 
the EGS or EHGRD. The flight hardware EIS was prepared and approved 
before starting any development effort ; minimum inputs for its prepara- 
tion were the experiment proposal, EIP, and compatibility assessment. 

The flight hardware EIS covered also the backup, qualification test, 
and flight-type training hardware, which were required to be identical 
in configuration with the flight article. The EiSs for other hardware 
were generally prepared on a deviation basis from the flight hardware 
EIS. 


The EIS outline, as prescribed by the EGS, is shown in Table 
A-I. |_NOTE : The JSC EIS, as per the EHGRD, was essentially Identical 

through the area of Performance and Design Requirements, but thereafter 
included more detail in the areas of Quality Assurance, Reliability, 
Verification, Configuration Management and Documentation. JSC utilized 
a separate Configuration Specification as the control document for hard- 
ware development, in lieu of the ParL II Eisj 

t c r initial approval, specification chances could be incor- 
porated only through CCB-approvcd Engineering Chan e Proposals (ECPs) 
and Specification Change Notices (SCNs). 


| 
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TABLE A-I . END ITEM SPECIFICATION OUTLINE (PER EGS) 


PART I. 

PERFORMANCE /DESIGN REQUIREMENTS 

1 . 

SCOPE 

(including Criticality Category) 


1.1 

Changes 


2. 

APPLICABLE DOCUMENTS 

3. 

PERFORMANCE 

AND DESIGN REQUIREMENTS 1 


3.1 

Performance 1 



3.1.1 

Functional (Overall System; Mechanical, Electrical/ 




Electronic and Other Subsystems) 



3.1.2 

Operability (Reliability, Maintainability, Useful Life, 




Natural and Induced Environments, Transportability, 




Human Engineering, Safety) 


3.2 

Interface Requirements 1 



3.2.1 

Flight Hardware (Flight Vehicle, Other Experiments, 




Ground Coonunications , Flight Crew, Mission, GSE, 




Facilities) 



3.2.2 

Zero Gravity Type Training Hardware 



3.2.3 

Neutral Buoyancy Type Training Hardware 



3.2.4 

Simulator Type Training hardware 



3.2.5 

ICD List 


3.3 

Design 

and Construction 



3.3.1 

Mechanical 



3.3.2 

Electrical and Electronic 



3.3.3 

Fluid (Gas and Liquid) 



3.3.4 

Debris Protection 



3.3.5 

Cleanliness 



3.3.6 

Test Provisions 



3.3.7 

Single Failure Points 



3.3.8 

Redundancy 



3.3.9 

Selection of Specifications and Standards 



3.3.10 

Materials , Parts and Processes 



3.3.11 

Standard Parts 



3.3.12 

Fungus Resistance 



3.3.13 

Corrosion Prevention 



3.3.14 

Interchangeability and Replaeeabilitv 



3.3.15 

Workmanship 



3.3.16 

Elec tromagne tic Interference 



3.3.17 

Identif ic at ion and Marking 



3.3.18 

Storage 



3.3.19 

Pyrotechnic Devices 

4. 

TEST /PRODUCT 

ASSURANCE REQUIREMENTS 


4.1 

Verification Matrix 


4.2 

Test Types 



4.2. 1 

Dew lopmen t 



4.2.2 

,!ual i f i cat ion 



4.2.3 

kel iabi li i \ 



,.2.4 

0 tiier Tests (Integrated S vs terns, Flight Ve r i 1 i e a t i or. , 




Post i light) 


4.3 

Rejection j 
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TABLE A-I. END ITEM SPECIFICATION OUTLINE (PER EGS) (Continued) 


5. DATA LIST 

6. PREPARATION FOR DELIVERY 

7. NOTES 

PARI II. PRODUCT CONFIGURATION REQUIREMENTS 

1. SCOPE 

1.1 Product Configuration Baseline Acceptance 

1.2 Changes 

2. APPLICABLE DOCUMENTS 

3. PRODUCT REQUIREMENTS 

3.1 Performance 

3.1.1 Functional Characteristics 

3.2 Configuration 

3.2.1 Manufacturing Drawings 


4. TEST /PRODUCT ACCEPTANCE REQUIREMENTS 

4.1 Acceptance Matrix 

4.2 Test Types 





b. Engineering Drawings. The ED prepared engineering 
drawings to control, by means of pictorial or narrative presentations, 
the physical and functional engineering requirements for each part of 
the hardware to be produced. The drawing tree progressed from the top 
assembly drawing to detail component and part drawings. They provided, 
directly or by reference, all data needed for use in conjunction with 
specifications, test procedures and reports, inspection procedures, 
acceptance and rejection criteria, processes, manuals, operational pro- 
cedures, safety precautions, surface cleanliness requirements, etc. 

The engineering drawings included: 

o All essential drawing information needed to permit an 

evaluation or a feasibility study of the proposed design, 
or to document the results of exploratory research or 
development effort* 

o Sufficient detail to enable evaluation and control of 
physical and functional design interrelationships of 
interdependent components, equipments, subsystems, 
systems, ground support equipment or facilities* 

o All drawing information necessary to support installa- 
tion, operation, maintenance and interchangeability 
during tests and operational use. 

o The necessary design, engineering, manufacturing and 
quality support information, directly or by reference, 
to enable the procurement, without additional design 
effort or recourse to the original design activity, of 
an item that duplicated the physical and performance 
characteristics of the original design. 

c. Technical Reports. The results of studies and analy- 
ses performed during the development effort were documented in tech- 
nical reports. The reports covered load analyses, stress analyses, 
trade-off studies, etc., and were not standardized in format. 

d. Review Minutes. Minutes were prepared for each PRR, 
PDR and CDR. The minutes for each review consisted of two parts. 

Part A provided an immediate record of the review proceedings and 
included all items requiring post-review actions. Part B was pre- 
pared after the final disposition of all Part A action items, and 
reported the final disposition of each. (See Appendix C .) 

e . Configuration Inspection (Acceptance) Re vie w Repo rt . 

A CIR Report was prepared for each acceptance review (see Appendix C) . 
IL provided a record of the review results, including: 
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o Action items with LiKir disposilion 
o Waivers or deviations authorized 
o Shortages authorized 

o Copy oL L he completed Form DD250 (Material, inspection 
and Receiving Report) 

3 o Quality Assurance Documents 

a. Acceptance Data Package, The ED prepared an Acceptance 
Data Package (ADP) tor each deliverable hardware end item. After deliv- 
ery, the ADP stayed with the hardware and was updated to reflect subse- 
quent usage. The hardware cusLodiaa was responsible for maintaining 
the ADP current as required. The package included but was not neces- 
sarily limited to the following: 

o Equipment logs (see item A.3.c) 

o Engineering drawings down to the replaceable component 
level (see item A.2.b) 

o Inventory of serialized components, including part number, 
name, serial number, and the associated experiment 
hardware subsystem 

o Report of actual weight and center of gravity 
o Operating, Maintenance and Handling (OM&H) procedures 
'see iLcm A. 7) 

o Calibration Data ReporL (see item A.5.e) 
o Listing of all Material Review Records (see item A.3.b) 

o End item Specification, Paris I and II or Conf igurat ion 

Spec i f icat ion (see item A. 2. a) 
o Certification that the hardware had been cleaned in 

accordance with the Contamination Control Plan (see 
item A.l) 

o Failure Reports and Failure Analysis and Corrective 
Action Reports (see items A.3.d &. e) 
o Configuration Inspection (Acceptance) Review Report 
(see item A.2.e) 

b. Material Review Records. A Material Review Board 
(MRB) at tile hardware development site was composed of ED design 
engineering and quality representatives and the EDC 1 s designated 
quality representative. The MRB reviewed and determined disposition 
of articles or materials submitted by ED quality assurance as *'non- 
conforming" with applicable drawings, specifications or other require- 
ments. Accurate Material Review Records of MRB actions, including 
assurance of effective remedial and preventive actions, were main- 
tained and incorporated in the appropriate hardware ADP. 

c. Equipment Logs. An Equipment Log was prepared and 
maintained for each major hardware component, subsystem, and s\sten 
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to document the continuous history of the item. Entries included, but 
were not limited to, the following: 1) date of entry, 2) identity of 

test or inspection, 3) environmental conditions, 4) characteristics 
investigated, 5) parameter measurements, 6) identity of instrumentation 
used and calibration dates, 7) record of all storage, operating, and 
test times, and listing of time/cycle critical items, 8) cumulative 
number of duty cycles, 9) discrepancies, 10) repair and maintenance 
records, 11) record of pertinent unusual or questionable occurrences, 
12 ) action taken to formalize quick fixes, 13 ) identity of individual 
making entry. The equipment logs, as part of the ADP, were available 
at all times for inspection and review with the equipment. 


d. Failure and Unsatisfactory Condition (PC) Reports, 
Failure and PC Reports were prepared by the developer for any failure 
where a system, subsystem, component or part was unable to perform its 
required function under the specified conditions for the specified 
duration* Each report contained the part number, name of part, serial 
number, part manufacturer, date problem was first detected, test being 
conducted \tfien the problem occurred, conditions at time of problem, 
problem description, problem cause (if known), and any other informa- 
tion considered pertinent. 


e. Failure Analysis and Corrective Action Reports. 

Failure Analysis and Corrective Action Reports were prepared by the 
developer for each reported failure. Each report referenced the Failure 
Report, defined the method of analysis, documented the results, defined 
the action(s) necessary to prevent recurrence of the failure, and 
included jus tif ication for the selected action. If the proposed cor- 
rective action required a change to the baseline configuration, the 
failure analysis and proposed corrective action were submitted with 
an ECP. After approval of the change proposal, the approved Failure 
Analysis and Corrective Action Report was submitted, indicating the 
need for reverification and containing provisions for signature close- 
out of the item. 


4 . Reliability Documents 


a . Failure Mode and Effects Analysis Reports. FMEA 
reports were prepared for each end item to identify critical failure 
areas and remove susceptibility to such failures. These analyses were 
performed on each component of the end item and each potential failure 
was categorized according to its probability of occurrence and conse- 
quent effect on mission success (see Criticality Categories, Section 
X). These reports served as an aid in proportioning the effort 
required for corrective design action and reliability control. Each 
report included a Single Failure Point Summary, a Hazards Summary and 
Reliability Logic Block Diagrams. The single failure point summary 
summarized all Category 1 and 2 single-point failure modes by identi- 
fying the: 1) item name, 2) failure mode, 3) effect of failure upon 
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l 1,0 system, '0 criticality of the failure, 5) means of detection, 
o) required corrective action, and 7) justification or rationale of 
acceptance it corrective action was not implemented. The Hazards 
Summary identified and categorized catastrophic or critical hazards 
in environment , hardware, test, training, operational procedures and 
interlace conditions and discussed steps to relieve 1 these hazards. 

The Reliability Logic Block Diagrams showed the functional inter- 
dependencies among the sysLem components so that the effects of a 
functional failure could be readily traced through the system. All 
redundancies or other means Lor preventing failure effects were shown 
as functional blocks or notes. 

b- Elec trical » Electronic a nd £ iec tr ome c hanical Farts 
List » An EEE Parts List was prepared to identify ail EEE parts in 
use” and included as a minimum the following: i) generic part, type, 

name and number, 2) common designation, 3) manufacturer f s name , 

4) manufacturer *& part number, 5} package type, b) specification name 
and number, 7} quantities used per replaceable assembly and identifi- 
cation of replaceable assembly, 8) limited life part restrictions, 
and 9) qualification methods and status. 

e. Materials List. A Materials List was prepared, identi- 
fying all nonme taliic materials in use, and also containing a summary 
of metallic materials used that reflected any recognized f lammabi li ty , 
toxicity or odor hazards inherent in the design through use of metal- 
lic materials. The Materials List included as a minimum the following: 
1) pari number, 2) major assembly part number, 1) generic identifica- 
t ion , 4) material manufacturer, 5) material specifications, b) trade 
name or commercial name and catalog number, 7) usage category, 8) weight 
per usage, 9) exposed surface area, and 10) method of verification and 
stai us . 

5. Test Documents 


a. Verification- Plan. A separate verification plan for 
each end iLem was prepared by the ED and submitted for approval at 
the PDR. It defined the verification methods (similarity, analysis, 
inspection, demons t rat ion , validation of records, or test) to be used 
to verify that the end item met each technical requirement in the EIS. 
For requirements to be satisfied by assessment, the plan described the 
specific Lvpes of analyses, inspections, etc, to be conducted (i.e., 
stress analyses, thermal analyses, radiographic inspections, etc), 
defined the objectives of these methods, and identified the documents 
that would contain the assessment. When a requirement was to be veri- 
fied bv test, the Verification Plan defined: specific tests to be 

conducted; equipment components, parts, etc, to be tested; test objec- 
tives; locations where tests were to be conducted; facilities and 
equipment support requirements; and t ime phasing ot the tests. The 
tost program was to provide only the minimum tests necessary, based 


on the criticality and complexity of the experiment. The entire 
spectrum oi tests was analyzed as an integrated effort to minimize 
test requirements and prevent duplication. Testing was conducted at 
the highest feasible level of hardware assembly. For Very simple 
experiments, the test plan, specification and procedure could be com- 
bined into the same document . 

b. Test Specifications. A Test Specification was pre- 
pared by the ED for each type of test defined in the Verification Plan. 
Each specification included, as applicable: test item nomenclature and 

identification; test objectives; quantity to be tested; test parameters 
or performance criteria, with limits or tolerances; acceptance and re- 
jection criteria; environmental conditions; hazardous operations or 
situations; reference to applicable safety standards, rules and regula- 
tions; allowable adjustment or maintenance operations; requirements for 
data recording, analysis, retest sad reporting of test results; and 
test article disposition* 


c* Test Procedures* Test Procedures were prepared by the 
ED for each type of inspection and test defined in his test specifica- 
tions. The Test Procedures prescribed steps to be accomplished in 
detail and sequence, test equipment to be used, calibration require- 
ments, layout and interconnection of equipment, safety practices (tor 
equipment and personnel) to be observed and criteria for passing the 
test, including tolerances. Development test procedures were not sub- 
mitted for approval; however, all other (qualification, acceptance, 
etc) procedures were submitted for EDC approval. 

d. Test Reports. Test Reports were prepared for each 
type of test conducted. Qualification and acceptance test reports 
were submitted at the CIR for review of their validity and verifica- 
tion of satisfactory tests. The test report contained an evaluation 
of test data, a comparison of test results with test objectives and 
design and performance requirements, a listing of any associated 
failure reports, and conclusions based on the evaluation. The report 
in many cases also contained an annotated copy of the actual test 
procedure . 


e. Calibration Data Reports. Where applicable, a Cali- 
bration Data Report was prepared from acceptance test results and 
became a part of the ADP. These reports provided the actual calibra- 
tion data sheets for each measurement produced or displayed by the 
experiment. For each measurement the report included the following: 


Descriptive title of measurement 
Measure me nt number 

Indicating device part number and serial number 
Component part number and serial number in whirl 
indicating device was installed 
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Original tabulation o£ actual calibration data points 
Original graph of calibration data 


This information was used for data evaluation during integration testing 
and mission data reduction. 


6. Development Status Report . A Development Status Report 
was prepared by the ED to provide the status of the total development 
effort at each program milestone. The report was an integrated effort 
covering the development of all the ED's hardware, including GSE. It 
included, but was not limited to, the following: 1) schedule status, 

2) mass properties status, 3) quality assurance, reliability and system 
safety status, 4) spares status, 5) delivery status. 


7. Operating Maintenance and Handlin g Procedures. The Opera- 
ting, Maintenance and Handling «M&H) procedures were prepared by the 
ED and included in the ABT, to define all procedures required during 
both flight and ground usage. The procedures contained all instruc- 
tions for operation, servicing, maintenance, calibration, handling, 
cleaning, storage, packing and shipping. Any limited-life or time- 
critical items were identified and replacement cycles defined. The 
procedures included all diagrams, exploded views, sketches, text, etc, 
necessary to permit efficient procedure accomplishment . They also 
clearly indicated any step which, if not correctly followed, would 
result in serious injury to personnel or hardware damage, and gave 
the reason for such warning. The flight hardware OM&H normally con- 
sisted of three volumes. Volume I contained a general description of 
the hardware and its interfaces; subsystem functional description, 
operational and design characteristics, limitations and restrictions, 
and controls and displays. Volume 11 contained the mission operational 
procedures for both normal and contingency operations, in a step-by- 
step checklist format that was used by the Mission Operations Center 
to prepare detailed checklists for the crew. Volume III contained ali 
necessary procedures to accomplish ground operations, maintenance and 
handling of the hardware (including recovery operations if applicable) ; 
this volume was used by the Module Development and operations centers 
to prepare their detailed test and handling procedures. 


8. Data Request Form . The standard format for the DRF , the 
formal instrument for identifying experiment data requirements, is 
reproduced in figure A-2. Contents of the various blocks in the DRF 
are self-explanatory from their titles. 
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Page 1 Of . 


DATA REQUEST FORM 

Skytob Progrom 


Period of Intorott 


Rt<)utst Contact 


DRF Control No. 


Exp/Syi No. 



Op. Nood Date 


Data Recipient 


Rev Data 


Dote Raq 


Organisation 

Phene 


efe fence Document: 


MRD Content 


soften 

ph*n* 

Signature 


MS F 0 - f orm ej (October |9?0) 


Hama 

AddrOSS 

Ptiana 



O' gen it at ion 

phene 

Signature 


In tear ate f 



HBHHHHHHHDlCniSnuTIICIHHHHHHBi 

Name 

0 rgani totion 
phene 

Signature 0 or* 

Hama 

Qrgeni xotion 
phone 

$«gne*ure Dote 


FIGURE A- 2. DRF FORMAT 
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B. 


Integration Documentation 


Integration documents vur e prepared Lo assure Liiat the experi- 
ment interlaces with the program were satisfactorily provided. Begin- 
ning with the experiment concept, the requirements lor program inter- 
faces were established and systematically compared with program capa- 
bilities, Requirement documents were prepared which in turn generated 
documents that defined the interfaces or identified how the requirements 
were to be satisfied. In general, these documents were prepared by or 
under the cognizance of the Integration Center or Module Development 
Center. Mission operational documentation, which also involves exten- 
sive experiment interfaces, is treated separately in Section C. 


K 

i 


1* Compatibility Assessment . When the experiment concept was 
originally considered for approval, compatibility analysis was initiated 
by the Integration Center. It compared all experiment requirements to 
program capabilities and reported the compatible areas as well as incom- 
patible areas. Modification of proposed experiment requirements was 
often necessary to produce a compatible experiment. After experiment 
approval, the compatibility assessment became a recurring integration 
document covering total compatibility cf all the integrated experiments. 
The review of major problems identified in the compatibility assessment 
was supplemented by bimonthly management review meetings held by the 
Integration Center and attended by representatives of the other centers 
involved. At these reviews, the status of the problems was presented, 
a plan agreed to for their solution, and action items assigned (see 
Appendix B) . 


2 • experiment Requirements Document . Alter the experiment was 
approved, the EDC (or in some cases the integration Center) prepared an 
LRD Lo specify the experiment requirements ior module and program inter- 
laces. These interfaces could be of a physical nature (electrical, 
data, control, crew, thermal, mechanical, stowage, etc) or program 
interfaces (integration test requirements, number of mission data takers, 
recovery requirements, etc). The ERD was approved by the EDC and became 
a Level II baseline document following experiment and module PRRs . As 
the program proceeded, various ERD requirements became formalized in 
other Level II documents such as ICDs, TCRSDs , and MRD, and were de- 
leted from the ERD to avoid redundancy. Table A-1I presents the stan- 
dardized ERD outline, as prescribed by an intercenter ,f ERD Instructions 11 
document . 

3* Cluster Requirements Specification . Since Sky lab involved 
several modules, an overall integration specification ior the assembled 
modules (cluster) was found necessary. This document, prepared b\ the 
Integration Center, was identified as tin Clusti r Requirements Spetj.fi- 
cation (CRS) , ami amp li. lied tin* general performance and di.si..n ir.u. ra- 
tion requirements ol tin* Skylab Program Spec i : ieat i on to ensmn that 




TABLE A-II . EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE 


EXPERIMENT DESCRIPTION 

1.1 Objective 

1.2 Concept 

1.3 Experiment Description and Function 

1.3.1 Experiment Equipment List 

1.3.2 Additional Supporting Equipment 

1.4 Relation to Other Experiments 

1.5 Cluster Requirements Imposed on Experiment 

MISSION ASSIGNMENT AND HARDWARE REQUIREMENTS 

2.1 Flight Assignsient 

2.2 Location Assignment 

2.3 Hardware Requirements (Number and types of experiment end 

items) 

DATA REQUIREMENTS 

3.1 Preflight Data Requirements 

3.2 In-flight Data Requirements 

3.2.1 Experiment Measurement List 

3.2.2 Spacecraft Systems Measurement List (Housekeeping) 

3.2.3 Photographic Data Requirements 

3.2.4 Other In-flight Data Requirements 

3.3 Postflight Data Requirements 

3.4 Data Return Requirements 

3.5 Special Handling Requirements 

3.6 Analysis and Processing Support 

FLIGHT VEHICLE SYSTEMS REQUIREMENTS 

-4.1 Structural and Mechanical Requirements 

4.1.1 Weight and Volume 

4.1.2 Dimensional Sketches 

4. 1.2.1 Stowed 

4. 1.2.2 Operational 

4. 1 . 2 . 3 Post -Ope rational 

4.1.3 Mounting, Alignment and Orientation Requirements 

4.1.4 System and Equipment Modifications 

4.1.5 Plumbing Requirements 

4.1.6 Fluid Requirements (Gaseous and Liquid) 

4.1.7 Accessibility Requirements 

4.1.8 Observation Access Requirements 
4.2 Environmental Requirements 

4.2.1 Thermal Requirements 

4.2.2 Atmos pile re Requirements 

4.2. 3 Radiation Requirements 

4.2.4 Lighting Requirements 

4.2.5 Other Environmental Constraints 





TABLE A-II. EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE (CONTINUED) 


4. FLIGHT VEHICLE SYSTEMS REQUIREMENTS (CONTINUED) 

4.3 Electrical Re qu ir eme n t s 

4.3.1 Power and Voltage Requirements 

4.3.2 Power Profile 

4.3.3 Other Power Characteristics 

4.4 Instrumentation and Communications Requirements 

4.4.1 Telemetry System Requirements 

4.4.2 Timing System Requirements 

4.4.3 Ground Command Requirements 

4.4.4 Voice Communication Requirements 

4.4.5 Displays and Controls Requirements 

4.5 Interface Requirements 
4*5.1 Interface Schematic 

4.5.2 Interface Identification 

4.5.3 Existing Hardware Interfaces 

4.6 Esqpendable Equipment Disposal 

5. EXPERIMENT AND FLIGHT VEHICLE POINTING REQUIREMENTS 


5.1 Experiment Pointing Requirements 

5.1.1 Target Description 

5.1.2 Experiment Pointing Accuracy 

5.1.3 Allowable Experiment Rates 
5.1.*+ Number of Performances 

5.1.5 Duration of Each Performance 

5.1.6 Time of Each Performance 

5.2 F light Veh ic le Pointing Requirements 

5.2.1 Orbit Requirements 

5.2.2 Spacecraft Orbital Location Durim 

5.2.3 Reference Orientation 

5.2.4 Spacecraft Pointing Accuracy 

5.2.5 Allowable Spacecraft Rates 

5.2.6 A1 lowab le S pac ec raft Ac cc lera t ion 


Each Performance 


5.2.7 Spacecraft Maneuvers Required 
6. FLIGHT CREW OPERATIONS REQUIREMENTS 

6. 1 Experiment Preparat ion Requirements 

6.2 Experiment Operation Requirements 

6.3 Post Operation Tasks 

6.4 Operation Schedule Constraints 

6.5 Crew Training Requirements 

6.6 In-flight Maintenance Requirements 


FLIGHT OPERATIONS REQUIREMENTS 

7.1 Flight Su ppor L Rcquireme nt s 

7.1.1 C ommunu List 

7.1.2 Suppor t Rc qu i remen t s 

7.2 Rc cow rv Support Requirement 



TABLE A-II. EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE (CONTINUED) 


8 . POSTACCEPTANCE TESTING 

8.1 Experiment/Module Integration Test and Checkout 

8.1.1 Receiving, Inspection and Handling 

8.1.2 Ground Personnel Participation 

8.1.3 Integrated Test 

8.1.3. 1 Test Types 

8. 1.3. 2 Test Locations 

8.1.4 Facilities 

8.1.5 Data Recording 

8.1.6 Ground Support Equipment/Test Equipment 

8.1.7 Services 

8.1.8 Special Test Constraints 

8.2 Pre launch Checkou t 

8.2.1 Receiving, Inspection, and Handling 

8.2.2 Ground Per sonne 1 Par t ic ipa t ion 

8.2.3 Prelaunch Test and Activities 

8. 2. 3.1 Test and Activity Types 

8.2 .3.2 Equipment Utilization 

8.2.4 Facilities 

8.2.5 Data Recording 

8.2.6 Ground Support Equipment /Test Equipment 

8.2.7 Services 

8.2.8 Special Test Constraints 

8.3 Ground Personnel Training Requirements 

9. RESUPPLY AND REACTIVATION REQUIREMENTS 

9.1 0: oital Storage Requirements 

9.2 Resupply Equipment and Materials 

9.3 Reactivation Procedures 

9.4 Special Requirements 


10. REPORTS OF EXPERIMENT RESULTS 




all hardware would sucr^ss 1 a i ly i unc Lion as an i 11 U'j^rat co system to 
accomplish mission objectives. in addition to tin- general requ i rumen t s , 
lik l RS addressed sonn spec i Lie requirements tor primary tunetional 
areas (i.e., structural, attitude control, electrical, control and dis- 
play, communicat ions and data, environmental control, crew, and caution 
and warning liigiiL systems; ground systems; and payload requirements 
imposed on the launch vehicle) . It also provided a comprehensive list- 
ing and description oi ail approved deviations to its technical require- 
me 11 L S o 
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4 e Interface Control Documents . Once experiment requirements 
had been baselined, immediate attention was given to providing the 
interface details. These details were documented by the Module Develop- 
ment Center in ICDs. Preliminary ICDs were reviewed and baselined at 
the experiment PDR. Three basic types of ICD were prepared for each 
experiment t 

o Mechanical /Environmental (weight, center of gravity, 
attachment provisions, structural loads, thermal 
environment, etc - see Table A-III) ; 

o Electrical (type of power, connectors, pin assignments, 
wire sizes, etc - see Table A-IV); 

o Instrumentation and Communication (number of 'data 

measurements, type, sample rate, etc - see Table A-V). 

In addition to the experiment - lo-modu lc ICDs, GSL and lac i lit y LCDs 
verv. also prepared as necessary to define the experiment -t o-t»SL 
and G S E -to-l'aci lity interface r e q u i r erne n t s . 

5. Moduli. Spec i f ic at. ions and Documents . Paralleling the 
experiment document at ion , the Module Development Center prepared a 
Module End Item Spec i i icat ion , nodule FMLA, and various other inte- 
gration documents that incorporated experiment information. typical 
oi the lat ter We re; the moduli Power Allocation Document , vuiicn inte- 
grated the electrical power requirements oi tin- module systems and its 
installed experiments; moduli* Measurements Lists, which identified and 
defined Lite instrumentation and communications services provided by 
Li ie module; module Critical Items List (CIL) , which summarized all 
Category 1 and 2 critical items within Lite module, including those 
identified tor experiments; etc. 

0 . Experiment Integration Test Requirements and Specifications . 
As described in Section V.C , the Integration Center coordinated prepara- 
tion or an E1TRS document whica compiled postal cep tance u st require - 
mil. is o ! all i he i xpi r inx nt s , anu provi did soma in! orma* ion i or t ne 
moduli and ir.it .■ r ai ed s\*s t «. r.: TuRSDs. FLuix A - i siiows tm iormt oi a 
tvpiiaL E LT RS pan*. 
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FIG URL A-j. EITRS FORMAT (SAMPLE) 










TABLE A-III. MECHANICAL /ENVIRONMENTAL ICD OUTLINE 


1.0 

Scope 


2.0 

Applicable 

Documents 

3.0 

Requirements 


3.1 Functional Requirements 


3.1.1 

Environmental 



3. 1.1.1 Spacecraf t /Launch Vehicle Imposed Environments 

3. 1.1.2 Experiment Required Environments 

3. 1.1.3 Experiment Imposed Environments 


3.1.2 

Interface Loads 

(Maximum Loads at the Attachment Interface) 


3.1.3 

Mass Properties 

(Weight, Moment of Inertia, Center of Gravity) 


3.2 Procedural Requirements (If Applicable) 

3.3 Physical Requirements 


3.3.1 

Mechanical (Drawing showing Structural Interface) 


3.3.2 

Envelope 


3.3.3 

Axes Definition 


3.3.4 

Alignment 


TABLE A-IV. ELECTRICAL ICD OUTLINE 

1.0 Scope 

2.0 Applicable Documents 

3.0 Requirements 

3.1 General 

3.1.1 Abbreviations 

3.1.2 Te rmi no logy 

3.1.3 Electrical Characteristics 

3.2 Interface Wiring 

3.2.1 Connector Designations 

3.2.2 Cable Pin Functions 



TABLK A-V. INSTRUMENTAL 1 LON AND COMMUNICATIONS 1CD OUTL1NK 


l . 0 Scope 

'.0 Appl icnh Le DoviuiK’nl s 

3.0 Requ.i. re men t s 

3.1 Te Lome try 

3.1.1 Data Signal Characteristics 
3. L . 1. 1 Analog Measuromen t s 
3.1.1. 2 Digital Measurements 

3.1.2 Signal Conditioning 

3.2 Commands 

3.3 Timing 

3*4 Correlation Data - (Measurement originating outside 

experiment, required during course of experiment operation.) 
3.5 Electromagnetic Compatibility 
3.5.1 bonding 


7. Test and Checkout Requirements and Specifications Documents . 
The module TCRSDs and the integrated system TCRSD were prepared by the 
Module Development Center and Integration Center. Those TCRSDs do lined 
the module and system acceptance requirements, spec i 1 icat ion criteria 
and constraints to be used in preparing the test procedures. The TCRSDs 
utilised the KITRS as t lie basis tor experiment test requirements. The 
module TCRSDs were utili/.ed at the module contractor's and Launch sites. 
The integrated system TCRSD was used only at the launch site * Hie TCRSD 
lormat was the same' as the KiTRS without the' olLeclivitv columns. 


8. Test Proc I'd ure s . Module and integrated system test ing was 
pe r t ormed in accordance' with detailed le'st proce'eiurcs writlen by tlu' 
Module' Development Center or the' Launch Ce'nte'r to satistv tin* require- 
ments and spec.il icat ions ot tlu* 1‘CRSDs • i'he procedures eoniained u 
description ot the test , test cont i gurat i on , special test requirements, 
data requirements, test evaluation, and step- by -step Lose periormance 
instructions. For experiment operating details, the QM&H manual de- 
livered with the experiment ADP was used. The HOC' supported t inal 
preparation at these procedures by reviewing them prior t o the test. 

An addendum to the test procedure contained a listing ot all test 
anomalies, anomaly descriptions, t rouh leshoot ing stops and corrective 
ac i i on t aken . 


h. Inst a 1 lat ion and Removal Procedures . Based upon the experi 
mont OM&H manual, module integration plans and the KRD, the Module De- 
velopment Center also prepared documents tor handling, installing., and 
r omov im; the experiments. These procedures i'on l a i ned , t er site, 

t 1 1 * v env i ronmen t a ! ami hand 1 i ng constraints, drawings nee ossa r\ t ei 


/ :> 



ton 



>x processes (Loading iilm, installing experiments, etc.),. 


siiovinu comply*, r > ~ , , _ . , . , _ 

detailed steps tor performing installation, removal and rdurbismi , 
all GSE/Facility ICDs , and a list of all GSE required. 


reference to 


C. Mission Operational Documentation 


1 Ope rations Directive (Program Dire ctive No. 43). A series 
of formal directives was issued by the Program Director, and controlled 
at Level I, to amplify the Program Specification requirements m specific 
areas. Program Directive No. 43 officially identified program objectives, 
policies and requirements; described the various Skylab missions, their 
specific objectives and requirements; and identified mission assignments 
and scheduling instructions for the individual experiments. 


2. Mission Requirements Document . The MRD provided the basis 
for mission planning and design. It was prepared by the Mission Opera- 
tions Center, based upon the Program Specification, Operations Directive, 
ERDs, and Experiment OM&H manuaLs. It defined the integrated functional 
and performance requirements to achieve program and mission objectives. 
Many subsidiary mission documents were prepared to implement the MRD 
requirements. These documents could expand upon, but could not conflict 
with the MRD contents. 


The MRD contained a definition o£ the mission objectives, a 
mission profile description, launch date(s), orbital parameters and 
vehicle attitude capabilities. General ground rules relating to in- 
flight operations were prescribed for use in flight planning. ie 
also defined, for each experiment, the detailed test objectives ( s) , 
requirements, test conditions and types of data required lor experiment 
accomplishment. The test conditions described the environmental limi- 
tations, pointing requirements, vehicle attitude stabi ity, c ee ne' 
Lolerances and all other constraints pertinent to experiment opt r 


The MRD was updated and expanded in periodic review cycles, 
under Level II. change control. 


3. Fli ght Plan . The Flight Plan, prepared by the Mission 
Operations Center, was a detailed schedule of all in-flight crew 
activities. It responded directly to the MRD and endeavored to satisfy 
all requirements and constraints specified therein. The scheduled 
activities for each crewman were laid out relative to a time base, 
usin'- 1 operation Limes which had been verified during crew training 
sessions. In addition, the summary timeline tormat (see figure A--+) 
provided a simultaneous display of related data such as day and night 
periods, beta angle, ground station contact Limes, vent times ana tape 

recorder usage. 


The graphical presentation utilized in the Flight Plan facili- 
tated the identification of conflicting requirements and constraint 
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v iolaL ions . Although not under formal change control, the Flight Plan 
v.as under continual revision, and each publication v.as widely distri- 
buted lor review and comment . The information required to produce tile 
Flight Plan was updated as required and stored in a data bank for use 
during tiie mission in the eompu ter-cont roi led , real-time Flight Plan 
generation . 

^ • Stowage List . Stowage lists were compiled and maintained 
by the Mission Operations Center to identify and track the proper loca- 
tion of all moveable equipment in the Skvlab modules throughout the 
mission's). The lists highlighted the article f s identif ication , weight, 
cumulative quantities launched and returned, and the planned stowage 
locations for launch, in-flight transfer, and return* A sample Stowage 
List format is reproduced as figure A-5. 

-* * Mission Rules * The Flight Mission Rules were a com- 

pilation of preplanned responses to possible in-flight contingencies. 
They r were prepared before the missions, and attempted to anticipate 
anomalies which might occur during flight, together with appropriate 
corrective actions. These rules were designed to reduce the response 
time required to cope with anomalous situations during the mission. 

They ".cere crucially important: in those instances where a particular 
malfunction might compromise crew or vehicle safety, thereby demanding 
immediate action. In less urgent circumstances, they assumed an ad- 
visory role, describing the previously agreed-upon action' to be followed 
after the anomaly's criticality had been determined (see Malfunction 
Procedures, item 8 below). 

b- Lxpc rinKMi t Operations handbook . Tile LOH was published in 
two volumes. volume I was system oriented and provided expcrimeni 
descriptions. Volume il contained detailed normal, backup, and mal- 
function operational procedures tor these experiments. As such, this 
document provided the preliminary input for crew training purposes and, 
with iced back from training, formed the basis for the crew checklists. 

7. Crew Checklists . The crew experiment checklists were 
detailed, step-by-step procedures to be followed for proper experiment 
operation, included in the onboard Flight Data File. The MRD, experi- 
ment GM£*H , acceptance and integration test results, EOH, and crew 
training experience were the principal inputs for these documents, 
they were updated as required during the mission b\ the mound support 
crew at the Mission Operations Center (e.g., to provide specific co- 
ordinates of an experiment target). 

8. Malfunction Proceu r._s . 11 u nature oi space ilium experi- 

mentation demands t hat experiment hardware possess a hich reliability. 

1 * ! b ‘ *’ iL d*. Vv. Lopi.ie p. I t U ge , eVil'C e] [.Oil V. U S made L O i USUl'e t !Ul t 1 |u 

possibil it.y 01 an. in-tlieht hardware malfunction was negligible. De- 
s p i ta ‘ tills, c xpe r i e ii c e ; 'i a s si \ own that failures will occur. A mn j o r 
advantage oi manned space i iiual is tile l r<. Wiin 1 s abi I i t \' t o m. pair 
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FIGURE A- 5. STOWAGE LIST FORMAT (SAMPLE) 

































n - V ;ork around many LaiLurcs. The Malfunction Procedures, included m 
tj K - onboard Flight Data File, provided tile crew with logical steps to 
De followed when anomalies occurred. These procedures, expressed m 
block diagram iorniat , were designed to rapidly isolate the anomaly to 
the subsystem or component which had tailed and, where possible and 
applicable, described a repair method or alternate procedure which 
would permit continued operation. In the event that the maitunction 
procedure did not result in a satistactory repair, the applicable mis- 
si on rule was invoked. 

9. Operational Data Book , During the mission, there may be 
occasions when the limit of certain design tolerances may be approached 
or exceeded, necessitating appropriate action. The ODB was a compila- 
tion of the operational performance data and limitations of all vehicle 
and experiment hardware. From the experimenter it required a descrip 
tion of the mass properties, structure and dynamics of the equipment, 
the effect of experiment operation on the spacecraft environment, the 
nature of the load it presented to the electrical power system, data 
instrumentation requirements, experiment pointing capabilities and all 
operational limitations and hardware constraints. 

10. Skvlab Experiment Systems Handbook . The SESH was a com- 
pilation of experiment functional flow diagrams and, where applicable, 
mechanical and electrical schematics, for use by the flight controllers 
during the missions. It was designed to assist in the rapid reso u- 
tion of real-time experiment anomalies. Pertinent operational and 
system constraints were identified, as were the interfaces between 
t'XpurLnifiUs, where applicable. 

H ' Facility Usu.rs Handbook . As part oi an Announcement oi 
Fli'ht Opportunity, advising the scientific community of the availa- 
bility of an experiment facility (e.g., EREP) , a Facility Users Han 
book was prepared by the Experiment Development Center tor distribu- 
tion to potential users. liie handbook identified the pliysical/1 unc- 
tional characteristics and operational capabilities of the taeility 
and its individual instruments. 
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A major feature of Sky lab experiment integration activities was 
he continuing compatibility assessment performed by the Integration 
enter. This activity assumed various forms as the program developed. 


During the program's formative stages, when many different 
missions and configurations were being considered, an extensive assess- 
ment was conducted to categorize over five hundred available or potential 
experiments into compatible, discipline -oriented payload groupings for 
performance on particular types of missions. While the early concept 
of numerous dedicated missions did not survive, these assessments were 
influential in selecting the initial experiment complement for the con- 
figuration and missions that were implemented. 


Subsequently, as new experiments were proposed for MSFEB con- 
sideration, an iniLial compatibility assessment was necessary in each 
case, to evaluate the impacts of the experiment requirements upon all 
other hardware and operational aspects of the program. Any incompati- 
bilities identified were resolved before the experiment was approved 
for implementation. 


Thereafter , a continuing surveillance was maintained of all per- 
tinent program documentation, information and activities to assure that 
un experiment requirements and constraints remained compatible vi * n 
aLl interfacin'.; cluster and moduli systems and operational plans. 

WiK-re incompatibilities were identified, the integration tenter coor- 
dinated and participated in their resolution. All involved agencies 
(Pi, ED, EDC , Module DeVe iopcr/DeVo iopmen t. Center, operations centers, 
etc!, as applicable) were consulted and mutually acceptable solutions 
established. Normally, tin- Intcgtation Center prepared and "precoor- 
dinated" anv necessary change package tor submittal to tin- eo.nizaut 
CCB (see Section IX) and maintained corrective action implementation 

When significant hardware changes were: involved, the affected 
developed was responsible- for preparation oi hie ECP. 


status . 
hardware 


Mane special studies were; also conducted to assess the compati- 
bility of associated groups of experiments with their common module 
interfaces. Some examples were: mult i -experiment usage of the Scien- 

tific Airlocks, module provisions lor storage and i nv i ronnunLal pi o- 
te'ction of assorted e-xperiner. t phot ograph ic lilm, launen pael uoeess 
r c q u i rvme n t s tor e x pt.* r i me n L s > t c . 
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The various compatibility assessment activities continued at a 
high level throughout the definition, development, and integration 
phases, and as a monitoring and evaluation function during the mission 
support phase. Table B-I identifies and defines the general scope of 
the 17 experiment compatibility disciplines that were initially checked 
and subsequently monitored for these assessments. figure 11-1 presents 
a matrix of the pertinent program documentation that was continually 
reviewed in the various discipline areas. 

Management visibility of the experiment compatibility status 
was provided by oral presentation of bimonthly reviews, and by broad 
dissemination of a monthly Experiment Compatibility Status Report. 

■ Representatives of the module development, launch, and mission opera- 

tions centers attended the bimonthly reviews and received the status 
report. A key feature of the monthly report was a compatibility summary 
of the status of each individual experiment relative to each of the 17 
compatibility disciplines (see figure B-2). The summary was supplemented 
in the report by detailed descriptions of current problem areas and their 
resolution status, including action items and suspense dates where 
applicable (see figure B-3). Once entered, problems could be closed 
and deleted from the status report only by issuance of a CCBD correct- 
ing the incompatibility, or by some equivalent positive action accept- 
able to the Integration Center. 

The evolution of these integration techniques provided a very 
effective means for the timely control of Skylab experiment compati- 
bility. 
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TABLE B-I EX PER 1 ME NT COMPATIBILITY DISCIPLINES 


DISCIPLINE 


DEFINITION 


Mechanical Verification that experiment mechanical inter face re 

qu irements are met for mounting, alignment, orienta- 
tion, plumbing, venting, sealing, and the use of 
observation windows . 


Weight and 
S towage 


Consumables 


Electrical 


Ins t rumen ta t i on 
and 

Communica t ions 


Verification of current experiment weights relative 
to experiment and module control weights; of experi- 
ment stowage provisions in terms of weight, volume, 
and location for each launch, orbital storage and 
return operation in the mission; and that all onboard 
experiment support equipment is available at the time 
and in the quantities required. 

Verification that experiment requirements for oxygen, 
nitrogen, water, and/or other consumables will be 
supplied either by the modules or by the experiments 
themselves. 

Verification that experiments are compatible with 
the electrical power provided by the module (voltage 
tolerances, power profile, and total energy); that 
all electrical interfaces are compatible (connectors, 
cables, etc.); and that EMI produced in the electri- 
cal system will not cause unacceptable degradation 
of the system or experiments. 

Verification that experiment measurements, house- 
keeping measurements, voice communication, and ground 
commands required for the experiments will be provided; 
that experiment equipment, data lurmats, and data raLes 
will be compatible with module requirements for record- 
ing and transmission to ground, and with MMC require- 
ments for processing and display; that all data 
correlation requirements (e.g., time, ephemeris , etc.) 
will be provided for ; and that experiment -requi. red 
data will not be lost due to EMI. 


Environments Verification of experiment compatibility with prelaunch, 

launch, orbital and recovery environments (temperature, 
humidity, pressure, acoustic, vibration, acceleration, 
shock, radiation, illumination) as specified in the 
CRS or defined by NASA-recognized analyses; and of crew 
and system compatibility with experimen t - induced en- 
vironments . 


Materials Verification that experiment materials are acceptable 

in accordance with the appropriate spec i f ica t ions as 
referenced in the CRS, or that waivers to these spec- 
ifications have been approved. 



TABLE B-X EXPERIMENT COMPATIBILITY DISCIPLINES (Cout.) 


DISCIPLINE 


Contamination 


Photography 


D K FIN I TION 


Evaluation of experiment susceptibility to contamina- 
tion from internal or external sources; determination 
of contamination produced by the experiments; and 
verification of ground contamination control procedures, 

Verification that experiment photographic requirements 
are met, including photographic support equipment 
(cameras, lenses, light, cables, etc.) and film; and 
that adequate environmental protection is provided 
for film. 


Experiment 
and Spacecraft 
Pointing 


Safety 


Systems Test 


Verification that experiment pointing requirements 
will be met when integrated into the spacecraft; and 
that requirements imposed cm the spacecraft, including 
orbit position for performance, orientation, stability, 
allowable rates and accelerations, and the necessary 
maneuvers, will be provided for. 

Verification of experiment safety plans and provisions 
for on-orbit operations. 

Verification of compatibility of all experiment handling, 
test and checkout plans with integration test planning, 
prelaunch maintenance, logistics, pad access, and launch 
cons tra ints . 


Ground Support Verification that GSE and facilities provided will 
Equipment, Facil- satisfy the experiment pos tacceptance handling and 
ities and Handling testing requirements with minimum duplication. 


Flight 

Plans 


Crew 

Interfaces 


Mission 

Support 


Verification of flight plan compatibility with experi- 
ment requirements, priorities, objectives, constraints, 
and interfaces. 

Verification of experiment-to-crew interfaces, includ- 
ing in-flight access, restraints and aids, controls and 
displays, in-flight maintenance, and crew training. 

Verification of plans for obtaining required evalua- 
tion data; for processing, display, analysis, and 
reporting of this data in support of the mission; 
and for analysis and reporting after the mission. 

Verification and comparison of required dates and 
delivery dates for experiment mock-ups, trainers, 
f 1 i gh t hard va re ( i ne hid i n b a e k u p unit), and GSE. 


Schedules and 
Hardware Status 




DOCUMENTATION (SAMPLE) 






IBILITY SUMMARY (SAMPLE) 





Experiment Compatibility Problem Areas (Contd) 
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FIGURE B-3. COMPATIBILITY PROBLEM DESCRIPTION AND STATUS (SAMPLE) 
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DEVELOPMENT REVIEWS AND EEKT IFIEAT LON 


This Appendix di’scr i bus the roqti irement s , responsibilities and 
niethodologv for accomp I i slumiU of the formal reviews and certifications 
which were key development checkpoints lor Sky lab experiments. ihe 
seven kov management checkpoints established by Sky lab Program Directive 
No. 11 were: 

PRR - Preliminary Requirement Review 

PDR - Preliminary Design Review 

CDR - Critical Design Review 

CIR - Configuration Inspection Review 

COFW - Certification of Flight Worthiness 

DCR - Design Certification Review 

FRR - Flight Readiness Review 

The Experiment Development Center was responsible for accomplishment of 
the first five of these (PRR, PDR, CDR, CIR and COFW) at selected end 
item levels. The last two reviews (DCR and FRR) were program-oriented, 
encompassing the total mission complex; they were accomplished through 
coordinated efforts of the development, integration, launch, and mission 
operations centers, and were conducted in a different format by the NASA 
Headquarters Program Director. Experiment involvement in the DCR and 
FRR is described in Section VI of the main text. 

Fach development review was a critical examination of documentation 
and pertinent hardware for compliance with program requirements and for 
compat ibilitv with related hardware and facilities. The reviews progressed 
chronologically from requirements (PRR), to design (PDR, CDR), to hardware 
acceptance (CIR) and formal certification (COFW). Each successive check- 
point provided a more comprehensive assessment of program accomplishment 
as it matured. 

A. Purpose and Scope of Reviews 

1. Preliminary Requirements Review . The purpose oi a 1RR was 
to verify by formal review the suitability of the conceptual configuration, 
and to establish a Program Requirements Baseline that would satisfy the 
experiment objectives and provide the basis for preliminary design. Review 
material included the experiment proposal, the approved KIP, the Compat i- 
bilitv Assessment, the ED f s Statement of Work (SOW), and initial versions 
of the ERD and EIS. The PRR established: 

o A preliminary EIS for the conceptual flight hardware configu- 
ration that would be expected to meet mission objectives and 
the required schedule. 



o 


Operational requirements of the experiment on the module, 
crew, launch, flight and recovery, as reflected in the 
preliminary ERD. 

o Required end items and schedule. 

o Feasibility and/or development tests required to select 
and substantiate design approaches. 

Minutes of the PRR were prepared, as described in Section A.2.d of 
Appendix A, and included all items requiring post-review action. These 
action items were to be completed prior to final approval of the Program 
Requirements Baseline. 

2. Preliminary Design Review . The purpose of a FDR was to 
verify by formal review the basic design approach for the hardware, prior 
to proceeding with detail design, and thereby to establish a Design 
Requirements Baseline. The FDR established: 

o The integrity of the design approach, by review of design 
analvses, breadboard models, mock-ups, circuit logic 
diagrams, packaging techniques, test and study results, 
reliability analyses, etc. 

o The compatibility of the design approach with EIS perfor- 
mance and design requirements, including interface compati- 
bility with other flight hardware, the flight crew, GSE and 
facilities. This was accomplished by review of preliminary 
design drawings, layout drainings, envelope drawings, 
schematics, performance characteristics lor functional 
compatibility, and available test results. 

o The producibility of the design approach with respect to 

cost and schedule impact, through the review of requirements 
for special tools, equipment, and facilities to manufacture, 
inspect and test the hardware. 

o The adequacy of the planned test program for the end item, 
by review of preliminary test plans. 

o The acceptability of the design requirement baseline con- 
figuration, through approval of the design approach. 

Minutes of the PDR were prepared and included all items requiring post- 
review action. These action items were to be completed prior to formal 
approval of the Design Requirements Base 1 ine configuration. 




*G»KVwrirv r 



is- 

E 


r 




( 

f 

E 


3. CrLt Leal i)es I g,n Review. Fiu 1 purpose ot a i i)R was to 
writs bv i o nna i technical review the completed detail. design at the 
hardware, and to establish a product ion Drawing Baseline brt ore the 
design was released tor mamii acture. I’he CDR established: 

o The integrity of the comp Let ed dosicji, by review ot. 
the drawings (as prepared for release to manufactur- 
ing), analyses, mock-ups, qualification status ot 
selected parts and materials, test data, inspeeta- 
bility , etc * 

o Compatibility of the completed design with ills per- 
formance and uesign requirements, as revised since 
PM, This included the exact physical and functional 
interface relationships with other flight hardware, 
the flight crew, SSE and faci 1 i ties » 

o The production baseline configuration for manufacture 
of the hardware, through approval of the completed 
design and associated documentation. 

o Adequacy of the planned test program, by baselining 
the Qualification and Acceptance Test Specifications. 

o Adequacy of the design from a safely standpoint , 

through a review ot design details and test results. 

o Adequacy ol tin* design i or operations, bv review ot 
engineering simulations, tests and study results and 
b\ examination ol mock-ups, operating procedures, and 
s vs tens pertomiance data. 

Mi mu e s ol the C DR wore prepared and included all items re- 
miiriiv.'. post -review action. fuese net ion items wem to be conip ii' ted 
prior to formal approval of the baseline coni igurat ion tor manutac- 
turi ng. 


q. Conti gu r a lion In s pec t Lon Re v i e w . Ihe purpose ol a C1R 
was to verify by formal technical review that the coni i. guration oi 
the end item as being of ft red tor delivery was in conformance with 
the baseline established at CDR (as modified by approved changes) . 
This was accomplished by establishing the exact relationship ol the 
end item as described by released engineering doe mm n La t ion to t ik 
end item as manui ac Lured and assembled. The CLR was most eliiciently 
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Phase L - Approximat c Ly one week pr Lor lo st art oi t innl 

expo r imen l hardware acceptance tests, review the 
qua! i. 1 Leat ion status and test data, cent igural ion 
and overall s la t us o l t he end i t em and i t s GSh . 

Phase 2 - Approximately one week prior to delivery, review 

the final experiment hardware acceptance Lest data. 

The CIR established: 

o That the hardware to be accepted conformed to Cite pro- 
duction baseline configuration, as documented v the 
released engineering, including all approved * - nges; 
and that the configuration of the Qualification lest 
hardware corresponded to the configuration of the 
flight hardware to fee accepted* 

o That the test program of the Verification Flan had been 
completed and that the verification methods and test 
results validated the acceptability of the hardware . 

o That all failures occurring after CDR had been reported 
and corrective action completed. 

o That Fa * lure Mode and Effects Analyses had been com- 
pleted a i J were acceptable* 

o That the Acceptance Data Package was complete and 
acceptable . 

o The va 1 id 1 tv oi tin.' ha rdware acc e pi anco test i ng , 
verified by a direct comparison ot acceptance test 
data with FIS pertormanec and design requirements 
and bv ver i f icat ion that the accept anco test s had 
been conducted in accordance with the approved 
Acceptance Test Specification and procedures. 

o A plan tor accomplish ing any open work items remain- 
ing tor fulfillment of the above requirements. 

o Identification of all waivers, deviations or 
shortage s authorized . 

The results ot the CIR were documented in a CIR Report (see Appendix 
A , sec t i on A . 2 . c ) . 

i # Ce r t i l i c a t ion o 1 Flight U o r i hi ne s s . ine purpose oi t ne 
COFK milestone was t o cert ii> that each experiment end i t em was a u»r,!- 
plele and qualified item oi hardware prior lo shipment , and was accom- 
panied bv adequate supporting documental ion. Tin eOFU vas prepared 


Vi 3 


prior to shipment 1 v om the point o 
hix:. The COFW certified that: 


i manufacture and endorsed bv Lhe 

o Complete spec i 1 ica t ions and drawings had been developed 
in accordance with ail program requirements. Addition- 
ally, that the exact re lat ionship of the hardware as 
manutac Lured and assembled had been established, and 
that shortages requiring resolution prior to FRR had 
been indicated on the DD-250 form. 

o Acceptance, qualification, and any required reliability 
demonstration tests had been successfully completed and 
had set specification requirements. 

o Departures from specification and drawing requirements 
had been approved by Material Review Boards in accord- 
ance with EXS requirements. 

o Critical hardware failures had been reported, analyzed, 
and corrected in accordance with EIS requirements. 

o The hardware qualification program had been satisfac- 
torily accomplished. 

o The hardware was complete and in accordance with the FIS. 

o Data tor operation and checkout was complete and com- 
pat ibi ■ . 

o Interface Control Document requirements had been met and 
interface compatibility was certiLied. 

o Shipping and t. ranspor 1 ahili t y requirements as s La ted in 
Lhe FIS had been met. 

o Delivery status information as required in the EIS was 
complete. 

o The DD-250 form was ready for signature. 

When equipment was shipped to an intermediate destination 
(center test tucili.lv or developer 1 ? plant) for additional work, 
further sign -oil oi the COFW by the cognizant center was required. 
Eventually, upon completion of the FRR, the COFW was jointly endorsed 
bv the Launch Center and the FDC. 
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B. Review Format and Activities 

The review description and requirements contained in tiiis 
section were generally applicable to all development reviews; however, 
flexibility was permitted to meet the requirements of each experiment 
review. For example, the formal procedure of using Review Item Dis- 
crepancy (RID) forms to document problem areas was properly followed 
for major reviews (e.g., for modules or complex experiments), but was 
occasionally supplanted by a simple Action Item Log to accomplish the 
same purpose in reviews of the less complex experiments. This flexi- 
bility was implemented by a Review Agenda prepared specifically for 
each experiment review by the cognizant EEC. 

Review personnel consisted of; 1) review teams or working 
groups » representing each appropriate technical discipline or program 
interest, to conduct the detailed technical review; 2} a preboard, to 
perform a screening and advisory function; and 3) the review board, to 
direct the proceedings and make final disposition of all pertinent ^re- 
view items. The board and preboard normally included representation 
from the EDC, NASA Headquarters, the Integration Center, the operations 
centers, the ED and the FI or Project Scientist. The designated cap- 
tains of the review teams also served on the preboard. 

Pre para t ions . The cognizant EDC scheduled the review 
date (s) and site, and appointed the review board chairman, who in 
turn selected Ills preboard chairman and team captains. Approximately 
two. months in advance, this group prepared the Review Agenda, notifying 
invited participants of review objectives and personnel, sessic l 
t iming , applicable documents to be made available, and planned devia- 
Lions from normal review procedures, if any. Al least Lwo weeks prior 
to PRR, PDR, or CDR, the EDC or ED delivered to each participant a data 
package, consisting of updated plans, the appropriate technical documen- 
tation, and RID forms. Participants were expected to familiarize them- 
selves with the documentation, and identify suspected discrepancies and 
problems, in advance preparation for the review. 

RECOMMENDATIONS: Apply the following criteria in prepara- 

tion for experiment development reviews. For maximum 

effectiveness , each review must: 

o Be conducted at the appropriate time --in particular, 
not prematurely with respect to data definition and 
availability. 

o Involve the nu'» st experienced technical personnel 
available to cover all disciplines that at tv cl tin- 
review sub jec t . 
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o Limit participants to the required discipline and 
project representatives, authorized to act for 
their respective organizations (including a single 
source of crew comments, consistent from one review 
to the next). 

o Have a data package that is complete, but minimal 

in volume, available to all participants sufficiently 
early to permit thorough evaluation. 

o Emphasize hardware as available. 

o Include assessment of test programs and results. 

2, Technical Review , Technical reviews began with a general 
technical briefing by the EDC/ED, to provide all review participants 
with common background information on development status and technical 
requirements and final instructions as to review procedures, criteria, 
and guidelines. 

Due to the relative complexity of the review materials, indi- 
vidual team sessions were scheduled for each applicable technical and 
management discipline. The team sessions opened with detailed presen- 
tations to assure maximum understanding of the technical materials 
subject to review in the team’s defined area of responsibility, as 
interpreted by the team captain. The remainder ol the team sessions 
were devoted to in-depth examination and discussion of the review 
material, leading to the generation, review and coordination of RIDs , 
and development ol recommendations for their disposition. The MSFC 
standard RID format is shown in figure C-l. The team members sub- 
mitted their discrepancies/probiems to the team captain to assure 
proper format, completeness , clarity, c oordinat ion , and that the 
content wa s w i thin sc o pc of the review guidelines and criteria. A i t e r 
his review the team captain could recommend to the originator that 
the RID be withdrawn, rewritten or combined with another RID ol the 
same intent. However, any action or changes to a RID during the team 
meeting and subsequent activities required the concurrence of the 
originator. RIDs approved for submittal into the review data flow 
were logged, submitted for the developer’s response, and coordinated 
with other review teams as required. The developer’s appointed lead 
representative for each Learn piovided or made readily available the 
supporting documentation, analyses or explanat ions required to clarify 
or resolve questionable areas encountered during the review. lie also 
coordinated preparation of the developer’s response to submitted RIDs, 
provided lia; for coordinating the team's activities with other 
t. v • ar>; , a i xl p t d t c am minutes. 
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3. f r e b oa r d Action . ihe pro board convened, bo lore the board 
meeting, to screen and categorize ail RIDs submitted bv the review 
teams. Raeii RID was considered individual iv by the preboard, combined 
vith others vile re possible, and assigned to one oi the 1. ol loving recom- 
mended disposition categories; 

A. Recommend acceptance as written 

B. Recommend acceptance with (stated) modifications 

C. Recommend acceptance for study 

D. Recommend rejection 

E. Refer to board for resolution 

The total RID package, accompanied by pertinent data to support the 
recommendations, was then submitted to the review board for final 
disposition* 

^ Board Action * The board reviewed the RID package 
and, after considering the preboard's recommendations, either approved f 

or disapproved each presented RID. Suspense dates were established 
for all items requiring further action. (As noted previously, the 
formal RID procedure was replaced in some reviews by a simple Action 
Item Log.) The official review minutes (or CIR Report) provided the 
formal documentation of the board's actions and directions. 

3* Follow-Up Action . The EDC was responsible for assuring 
sat is l actor y review follow-up, i.e., t hat approved RIDs were imple- 
mented, directed Studies completed, and appropi i a L e action taken to 
close ail remaining open items by tile prescribed suspense dates. 

Upon completion oi ail required tollov-tip activity, tin- 1 inal review 
minutes were prepared and distributed by tin ELXJ, documenting the 
closeout, actions and dates, and certifying to the Program Director 
tiiat the review objectives had been met. 

RLC0MMLNDA1 ION ; Emphasize Liu 1 importance ot adequate 

toi low -up and formal closeout of ail RIDs or review 

action items, and timely dissemination of this infor- 
mation to all involved program personnel. 
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DESIGN CONSIDERATIONS 


The following experiment design considerations are categorized into 
those applicable to flight hardware and those applicable to GSE. These 
considerations v ere usually specified as requirements in either the CRS 
or the experiment EIS. Some considerations were only indirectly applic- 
able to design (i.e. , identifying operational methods or procedures that 
might influence the design). The importance of applying these design 
criteria was directly related to the criticality category of the experi- 
ment, i.e.: 


Category 1: Hardware whose failure could adversely 

affect personnel safety. 

Category 2: Hardware whose failure could result in not 

achieving a primary mission objective, but 
would not adversely affect personnel safety. 


Category 3: Hardware whose failure could result in not 

achieving a secondary mission objective, but 
which would not adversely affect personnel 
safety or preclude the achievement of any 
primary mission objective. 

Category 4: Hardware whose failure would not result 

in any of the above. 


A. Flight Hardware 

1. Flight Operation General Constraints 

a. Safety of the crew and safe termination of the mission 
were overriding design criteria. 

b. All components that controlled safety-critical functions 
were required to be designed to operate in a vacuum. This was consid- 
ered a requirement even for hardware normally located in a pressurized 
environment. 


c. Efforts were made to minimize the number of single fail- 
ure points (SFPs) in the design; rationale to justify acceptance of 
those SFPs that did exist was a prime consideration in design and 
acceptance reviews. Redundant systems, however, were to he provided 
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only If considered necessary to ensure crew safety or primary missic 


success . 


d. Wherever possible, opportunities for human error were 
minimized by designing connecting parts (e.g., fluid line or electrical 
connectors that might be reversed in mating) so that they would be 
physically incapable of being installed improperly. 

e. The experiment was designed to satisfy its own objectives, 
independent of the failure of another experiment. 


the design. 


f. Wherever feasible, flight-proven hardware was utilized in 


g. The module generally provided the following subsystems: 

1) Data Recording, 2) Power Distribution, 3) Pressurization, 4) Attitude 
Control, 5) Voice Communications, 6) Atmospheric Circulation, 7) Module 
Lighting, Food, Water and Waste Management, and 8) Central Caution and 
Warning System. 

2. Flight Operation Mechanical Constraints 

a. All experiment hardware having a crew interface was re- 
quired to remain within touch temperature limits of 55°F to 105°F. 

b. The following types of hardware were required to be 
delivered to the Module Development Center: 

(1) Mechanical interfaces tool (a tool that could be 
used to verify mechanical interlaces prior to installation; e.g., to 
locate bolt holes). 

(2) One full-scale mock-up of the experiment that, as 
a minimum, satisfied mechanical and crew interfaces. 

(3) One flight unit. 

(4) One complete set of GSE capable of verifying inter- 
faces and checking out the experiment to acceptance test requirements. 

c. Packaging. Experiment equipment which was stowed during 
the launch phase of the mission, and then transferred to a use location, 
was required to satisfy the following specifications: 

(1) Package limited in size to 20” x 25” x 40 n and in 
moment of inertia to less than 65 lb-in-sec^, and allowing adequate 
visibility during transfer. [NOTE: Skylab mission experience indi- 

cated no difficulty in handling large masses in zero g; however, the 




cross-sectional area of 20" x 25" was considered a realistic limit from 
the visibility standpoint.] 


(2) Hinges designed so that all hinged devices remain 
as positioned by the crewman. 

(3) Rounded edges and corners of packages and containers 

(4) Package fasteners able to withstand prelaunch, 
launch, and flight loads and: 

(a) Designed to prevent inadvertent operation. 

(b) Simply operable with either a bare or a pres- 
surized-gloved hand, without requiring extensive astronaut stability 
aids. Sky lab orews indicated a preference for magnetic or lift-handle 
latches . 

(5) Each package marked to indicate: 

(a) Proper mounting orientation. 

(b) Equipment-peculiar precautions. 

(c) Operating instructions, where feasible. 

(6) Cameras/film canisters, and other equipment trans- 
ferred during EVA, designed to meet the following requirements: 

(a) Capability for one-hand operation. 

(b) Capability for tethering. 

(c) Mounting provisions compatible with equipment 

transfei devices. 

(7) Package mounting provisions designed to avoid pro- 
viding a space for floating articles to pass behind and/or accumulate. 

3. Flight Operation Electrical Constraints 

a. Module power provided to experiment interfaces had the 
following characteristics: 

(1) Two -Wire System. Power was distributed by a two- 
>ire system. The system did not use module structure for return of 
l irrent to the power source. 




(2) Grounding. Any one set of negative buses was 
referenced to the structure at only one point. The experiment could 
not use module structure for return of current to the power source. 
The module provided the single-point ground. 

(3) Bonding. Electrical bonding and grounding of the 
experiment was in accordance with MIL-B-5087 , providing a radio fre- 
quency ground reference plane, a fault current return path, and a 
discharge path for lightning and static charge. 

(4) Circuit Protection. All experiment positive 
polarity lines of the DC distribution wiring were protected with 
circuit breakers or fuses provided by the module. Use of fuses was 
minimized . 

(5) Crew Mating or Deraating of Connectors On-Orbit. 
The presence of power in the connectors during mating or demating by 
the crew was circumvented by design or procedure. Connector design 
or application precluded mismating. 

(6) Characteristics of Unregulated 28 V DC Power at 
Interfaces. The voltages at module interfaces met the following re- 
quirements : 


(a) Bus Noise. The total AC components of the 
voltage could not exceed 1.0 volts peak-to-peak for all frequencies 
from 20 Hz to 20 KHz. 

(b) Under and Over Voltage. Under and over 
voltage with a duration greater than 10 microseconds and less than 
100 milliseconds could not exceed the limits 28 + 4 by more than 3 
volts . 


(c) Transients. Transient voltage with a dura- 
tion of less than 10 microseconds could not exceed + 30 volts relative 
to the limits 28 + 4 . 

b. The module provided interface cabling: 1) between 

sensor ad control panels, and 2 ) between experiment hardware com- 
ponents if the cabling required mechanical support from the module. 

c. Experiment electrical design considerations were: 

( 1 ) The experiment provided a rapid means of switch- 
ing off power under emergency conditions. 

(2) The experiment control panel provided a positive 
indication of power-on, current level, and power-off status. 
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(3) Experiment saf ety— critical and nonsafety-critical 
circuitr T were isolated from each other, 

(4) Secondary power sources were provided for experiment 
safe ty -critical functions . 

(5) Experiment safety-critical electrical components 
were protected against the effects of liquid leakage, moisture, con- 
densation, vibration, arcing contacts and corona. 

(6) Experiment electrical disconnects were located 
separately from hazardous fluid disconnects, were qualified as ex- 
plosion-proof and would not have power applied to the connection 
during or after disconnect* 

(7) If batteries were used, they were designed to 
prevent danger of explosion under any conditions. 

(8) Cabling was placed so that it could not be sub- 
jected to loads for which it was not designed (e.g., use as a hand- 
or foot-hold) . 

(9) Use of high-voltage systems was minimized. 

d. The design of an experiment was required to satisfy 
EMI criteria that met the following minimum requirements: the oper- 
ation of the exp. iment in any mode (powered or unpowered) could not 
degrade the performance of another subsystem relative to that sub- 
system’s performance criteria. The hardware would satisfy the single- 
point ground requirement and meet EMI MIL-STD-461. Verification of 
this was required during the qualification/development phase, and 
evidence of meeting these criteria was included in the ADP. 

e. Pyrotechnics 


(1) Use of pyrotechnics by experiments was minimized 
and required approval by NASA. 

(2) Pyrotechnic initiators could not be susceptible 
to ignition in the EMI environment of the module. 

(3) The arming of pyrotechnic devices was protected 
against accidental operation. Arming and safety were clearly indicated, 

(4) Pyrotechnic exhaust products were contained or 
controlled to prevent ignition of combustibles. 
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(5) The pyrotechnic logic circuits received power 
from a source other than the pyrotechnic initiation batteries. 

(6) Pyrotechnic devices required for safety were 
designed to allow verification. 

(7) Pyrotechnic firing circuits were protected from 
electrostatic charge buildup. 


(8) Sequence logic and pyr echnic firing circuits were 
required to be at least "fail-safe/fail-st a". 

4. Flight Operation Controls and Displays Constraints 

a. Circuit P rotec tion. Circuit breaker devices had aaaual 
reset capability and a visual display of position. 


b. Panel lighting. Console floodlighting, electrolumi- 
nescent panel lighting, and numeric displays were controllablein 
intensity steps at the panel or console. Lamp testing capability was 
provided for^anel displays. Radiation or luminescent type paint was 

not allowed. 


c Emer gency Lighting. The module provided the manual 
or automatic emergency lighting of the work areas. This requirement 
could be satisfied through the use of overhead emergency lighting. 


d Automatic /Manual Override. Controls and displays pro- 

vided the ca^abTTIFy^^ manual" overrTde of critical automatic systems 
to assure mission success or crew safety. 


e. Gr ound/Crew Operations . Experiment displays for ground 
and crew controlled systems reflected true system status. L N0TL: Sorae 

problems were encountered during the missions with inaccurate or un- 
reliable film and magnetic tape usage indicators .J 


f. Pyrotechnics Control^ The flight crew was the sole source 
of control of all pyrotechnic "devices required for on-orbit operations. 


g . Redundancy Contro l. Crew controls were provided for 
selection of redundant system capabilities. 

h. All controls and displays were recessed or provided with 
"bump-proof" switch guards, especially for panels located in high-traffic 

areas . 


i. Operation of experiment controls was limited to one-man 
operation, i’.e., no single experiment operation required two crewmen 
s imul taneous ly . 
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j. The crew monitored the progress of each experiment 
observation and were provided the capability to terminate observation 
due to lack of data quality. 

k. Instruments provided automatic cal ibra t ion , but pro- 
vided crew capability to initiate a calibration procedure. 

l. Where feasible (and not excessively time-consuming), 
crew capability to perform a function effectively was utilized instead 
of automating the function. 

m. Experiments were designed to operate in a powered-down 
mode during launch and reentry phases. If any experiment operation 
was required during these phases, it was monitored and controlled from 
the module. 

5. Flight Operation Crew Interface Constraints 


a. To the maximum extent possible, crew mobility/s tability 
aids for experiments were preinstalled. 

b. The crewmen were alerted to any existing or impending 
crew hazard condition by an appropriate signal to the Caution and Warn- 
ing System. 

c. Attachment provisions for mounting the car'ry-in equip- 
ment, instruments and devices, if any, were pro ins ta 1 led in the module 
prior to launch. 

d. All launch-stowed experiment equipment was stowed such 
that it could be obtained without EVA. 

e. The module generally provided the following crew aids 
and restraints: 

(1) Provisions for locomotion and restraint were 
located throughout the module to facilitate crew movement between 
various work stations. 


(2) Both permanent and portable general restraint 
devices were provided, to allow the crew to adequately perform acti- 
vities at the various crew stations. 

(3) Adequate foot restraints were provided each crew- 
man for use while performing normal or contingency tasks. 

f, i.YA tasks, including contingencies, could not require 
more than two crewmen (i.e., at least one crewman remaining inside the 
spacecraft at all times). 
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g. A manual backup mode was provided for all mechanical, 
EVA, and film magazine transfer devices. 

h. EVA crew work stations at the experiment were illumi- 
nated to 5 f t-lamberts minimum. 

i. The module provided the capability to turn off all 
external lights, either by crew or ground command, while performing 
light-sensitive experiments. 

j. Human Engineering. MSFC-STD-267 or MIL-STD-1472 were 
applied as guides for standards and practices for > T uman Engineering 
design. 


a. Fire, Toxicity, Radiation 

(1) Nonflammable structural materials were required 
in the module environment. Interior walls and secondary structure 
were constructed of self-extinguishing material. 

(2) To the extent necessary to ensure crew safety, 
materials selected for use in habitable areas were nonexplosive, non- 
flammable, nontoxic, and low- outgas sing under normal operational con- 
ditions as well as under conditions of depressurization. 

(3) Experiment radiation sources required NASA EDC 
approval for usage. 

b. Contamination Control 

(1) Shields 

(a) Contamination-sensitive elements were located 
to take maximum advantage of natural shielding by the vehicle structure. 

(b) Contamination-sensitive elements were shielded 
from any direct impingement of the attitude control system or venting 
contaminants, unless such shielding would be detrimental to the opera- 
tion of the contamination-sensitive element. 

(2) Covers 

(a) All optical instruments exposed to the external 
environment were protected from contamination during non-da ta-taking 
periods by movable covers over the instrument aperture. 

(b) Instrument covers were designed so that the 
most probable failure modes were in the open position. A backup 
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,u' t i vat i on 


mechanism to normi t emergency cowr open i ng was provided. 


Storage containers wo to prov ided tor coni ami - 
nant - sons it i ve oKpo r i uonts which wore stowed in tin' module. Containers 
were atmosphere- 1 ight and capable of dry nitrogen purge or evacuat ion 
alter insertion ot the experiment tor storage. 

(3) Material Selection. All materials used in con- 
struction of experiment and module hardware were evaluated tor out- 
gassing and dusting characteristics. Hie following specifications 
were applicable : 

(a) Material Outgassing Control. Materials se- 
lection conformed to the requirements of the program specifications 
(e.g.* 50M0244? , ATM Material Control for Contamination Due to Out- 
gassing). 

(b) Material Dusting Control. All materials were 
selected for minimum dusting, powdering, or f laking characters tics . 
Where no acceptable material to perform the function was available, 
covers or coatings were used to contain the dusting products, or other 
protective means (such as filters > were provided for redact ion of dust 
products entering the cabin or external atmosphere. 

^4) Wherever practical, mirrors, lenses, prisms, 
windows and other instrument optical elements that were expected to 
he degraded hv contamination were designed so that they could he 
periodical Iv replaced hv the crew wi th a spare lemont • 

pS> : leetric heaters on windows, lenses and mirrors 
were used whore practical to maintain the optical clement at an ele- 
vated temperature in order to pi event contaminant deposition, ot * o 
periodicallv heat the optical element vwimlow'* to drive ot t accumu- 
lated interna! coiulensa t ion . 


Photograph ic lilm was packagt'd in canisters to 
reduce possible contaminat i on effects prior to camera loading. n ro~ 
mission film testing revealed that certain film tvpes (in paiticulat , 
Schulman types, non-overcoa ted ) are susceptible to severe logging in 
the presence of imn-anodized aluminum or copper; these materials should 
he avoided! in design ot film storage containers. 


Venting and tkimping 

(a ) W a s t e si o rage t a n k s we i 
to allow a minimum ot one orbit's ac arm 1 n t i on 1 
design goal to store all liquid wastes tor the t 
period was actual *v achieved. > 


s we r e o 1 a d equal e s i ** e 
ion between dumps. (The 
the entire ope* at i anal 


itm* 




(b) Waste vents were positioned as remotely as 
possible from sensitive surfaces and were directed so that minimum 
impingement occurred on any module components. 

(c) Nozzle orifice design and discharge pressure 
were chosen to provide the minimum practical cone angle pattern for 
tiie discharge stream. Waste dribble at the beginning and end of a 
dump wa s mi n imi z e d . 

(d) Solid waste was packaged and stored wherever 
possible# If dumping was required, all solid waste was dumped into 
the waste tank in packaged form# Dumps were timed to occur between 
operations of critical experiments# 

(8) to ovoid contamination, dry lubrication was the 
preferred method for mechanisms exposed to space. 

7* Ground Operation Constraints for Flight Hardware # 

a. General Constraints 

(1) Experiments were installed in the module prior to 
installation of the module on the launch vehicle. 

(2) Ail subsystems included provisions for deactiva- 
tion and monitoring required to assure personnel and hardware safety. 

(3) Ihe experiments were designed to allow integration, 
checkout, operation, refurbishment and maintenance activities to be 
performed in either horizontal or vertical position. 

(4) All hardware was capable of satisfying and main- 
taining Glass 100,000 cleanliness as a minimum. 

b. Meehan ica 1 Constr aints 

(1) Interface cables and fluid lines were of suffi- 
cient length (service loop) to allow interface connections to be made 
before mechanical mating of the experiment 

(2) Interface fluid lines and electrical cables were 
designed so that individual cables or lines could he removed without 
disrupting the integrity of adjacent lines. 

(3) Transportation and handling equipment was designed 
to ensure that flight structures were not subjected to transporta t i on 
loads more severe than flight design conditions. 
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(4) Design of the experiment minimized problems due to 
moisture condensation and dripping. 

(5) The design and routing of flight and GSH cables 
and fluid lines was such that these cables and fluid lines would not 
pose any obstruction to module egress or be subject to damage. 

(6) Where possible in the design of the experiment, 
consideration was given to using captive-type fasteners for internal 
mounting of experiment components, to preclude loss of attachment 
hardware. 

(7) Experiment therroal control subsystems were designed 
so that constant or periodic circulation of fluids was not required 
during periods of power-down or storage, and to provide ease in the 
servicing of fluids including fill, drain, and dry operations. 

c. Electrical Constraints _ 

(1) Instrumentation system capabilities and sensors 
required to support ground test activities were included in the flight 
hardware wherever practical, in order to minimize the requirements for 
separate ground support equipment. 

(2) Where feasible, pyrotechnic devices were category 
B as defined in CP-469, Explosive Safety Handbook (i.e., ‘"Category B 
electric-explosive devices are those which wiLl not, in themselves or 
by initiating a chain of events, cause injury to people or damage to 
property"') . 


B. Ground Support Equipment 


1 • General 


a. Onboard monitoring and control oi those operations which 
might be hazardous to ground test personnel were capable of being moni- 
tored and controlled by GSH. 

b. CSC required lor support oi ground testing, monitoring, 
and servicing activities was minimized by making maximum use of the 
flight subsystems to support these functions. CSE related to ground 
servicing included provisions for external excitation voltage and 
monitoring capability, to preclude the necessity ol internal power-up 
for these activities. 

c. Development testing oi CSi. was required only when it was 
impractical, impossible, hazardous or not cos t -e 1 1 ec t ive to rely solely 
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on an engineering analysis or acceptance verification to establish func- 
tional performance. 

d. Qualfication testing was accomplished on an exception 
basis only, for those items of GSE which cuuLd not be qualified by 
analysis or similarity. 

e. Experiment-specific GSE was provided by the ED. This 
GEE was designed to interface with standardized facility support inter- 
faces for power, fluids, etc. 

f. The design of the GSE took into consideration the existing 
facilities' capabilities at the module integration site, launch site, 
and any other users' facilities, as applicable. Every effort was made 

to provide identical sets of GSE for use at the various test locations. 

g. Means were provided for controlled movement of hardware 
that was not easily hand-manipulated (e.g., tracks, guides or other 
restraining devices with spacing and friction controls) , to minimize 
the potential of damage to adjacent equipment and hazards to personnel. 

h. The experiments were protected as necessary during all 
handling operations. 

i. Containers for transporting hazardous material had ade- 
quate handles and lids and indicated when they were positively closed. 
Also, easy-to-recognize markings identifying contents, information or 
special handling notes were provided, 

2 * Design and Construction . GSE design adhered to known 
state-of-the-art and to the selection of proven parts, materials, and 
processes to tie degree practical. The design was restricted to the 
accomplishment of the GSE requirements. 

a. Operation Periods. After adjustment, GSE was designed 
to operate for a period commensurate with the function being performed, 
without requiring readjustment of controls when set for specific opera- 
ting conditions. 


h. Redundant Electrical Circuits. Redundant electrical 
circuits in GSE were not routed through the same connector. 

c. Operating P o wer. GSE was designed to be compatible 
with the power existing at the facilities to be used. 

d. Ra cks and c onsoles . The design oi subassembly racks 
and consoles included entry access for cables and cooling systems that 
were compatible with the facilities in which they were to hi os, a. 
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E 1 u i d (Cns and Liquid ) . Tin* GSE necessary to support 


fluid systems t tans for red , conditioned and/or stored the fluid suit- 
able for the ultimate system usage. 

1. Cleanliness. GSE was <* signed, maim lac Lured , assembled, 
and handled in a manner such that its presence* and/or operation in the 
applicable clean areas and flight vehicles would not violate the clean- 
liness levels maintained therein. In cases where CSC was used for the 
transportation, handling or removal of experiments, the < *S Id was designed 
to provide adequate means of contamination control consistent with the 
cleanliness levels of the module involved. 

g. *^ es fc Provisio ns . USE was designed so that failure 
within the GSE or interruption of power would not cause failure or 
damage to the flight hardware being tested. Conversely, failure of 
the flight hardware being tested could not cause failure or damage to 
the GSE. 

j h. Single Point Fa ilu res. GSE was designed so that a 

single point failure would not affect crew or ground personnel safety, 
cause loss of flight hardware, prevent or compromise accomplishment of 
a primary mission objective or cause a launch to be rescheduled. 

i. Standard Parts. NASA, Air Force-Navy (AN), Militarv 
Standard (MS) or joint Air Force-Navy (JAN) standard parts were used 
in GSE wherever applicable. 

j. Corrosion Prevention. Metals use 1 in GSE were of the 
corrosion-resistant type or suit bly treated to resist any corrosive 
conditions likely to be met in manufacture, assembly, testing, servic- 
ing, storage or normal service use. 

k. E l.ec tromagnet ic Inter T erence . Electrical and electronic 
GSE was designed to perform as specified when operating either inde- 
pendently or in conjunction with other equipment with which an elec- 
trical connection was made, or which may have been installed nearby; 
and would not, in itself, be a source of interference which might 
adversely affect the operation of other equipment. GSE was designed 

to meet the requirements and limits of MIL-STD-461. (Reference 
MIL-STO-462). 

l. Single Point Electrical Ground ing. All units (racks, 
consoles, enclosures) using or generating electrical energy were pro- 
vided with an accessible and clearly marked ground stud for single 
point grounding purposes. The DG resistance between any metal part 
oi the units (covers, lids, hinged doors , etc.) and the ground stud 
could not bo greater t nan IG-0 milliohms. 
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3. Maintainability . Maintainability criteria for GSE were 
specified to satisfy the following requirements: 

a * Accessibility . GSE was designed to permit ease of 
access to accomplish maintenance functions, i.e., inspection, servic- 
ing, adjustment, calibration, or repair. Inspection, maintenance or 
test locations were identified and easily accessible. 

t>. Disassembly Provisions. GSE was designed to permit 
ready disconnection, removal and replacement of major assemblies or 
components through use of modular construction design principles. 

i c. Environmental Requirements. GSE was capable of success- 

I fully performing the required functions during or after being subjected 

t0 the natural and Induced environments encountered during each of the 
modes of transportation, handling, operation and storage. 

d * Transportability. Wherever possible, GSE was designed 
to withstand handling and transportation environments without the nec- 
essity of special containers, or the necessity of monitoring critical 
environments to verify that design limits had not been exceeded. 
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EXPERIMENT TESTING 


A, Development Phase 

Requirements . Experiment hardware acceptance was contin- 
gent upon prior verification that the end item would meet each technical 
(performance, interface or design) requirement of the applicable EIS. 
Verification could be accomplished either by assessment or by test (or 
a combination of the two)* Commonly used assessment methods were: 

o Similarity : Used when it could be shown that the 

article was identical or substantially similar in 
design, manufacturing processes, and quality con- 
trol to another article that had previously been 
qualified to equivalent or more stringent criteria. 

o Analysis : Used in lieu of testing whenever it 

could be shown by generally accepted analytical 
techniques that an article would meet the appli- 
cable technical requirements. 

o Inspection : Used when it could be shown that 

inspection techniques were adequate to assure 
that the article would meet the applicable tech- 
nical requirements. Inspection was used to veri- 
fy construction features, compliance to drawings, 
workmanship, and physical condition of the article. 

o Demonstration : Used when it could be shown that 

demonstration was adequate to assure that the 
article would meet the applicable technical re- 
quirements. Demonstration was used to verify 
such requirements as service and access, handling, 
convenience and ease of operation. 

o Validation of Records : Used when it could be 

shown that records would substantiate manufac- 
turing processes, materials, traceability or 
test history performance. 
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for ,\isi s whom .iriSi ssuk iH methods i\ not appl. i cable , it was generally 
m i\ ssaiv to accomplish vcr i 1 i cat ion in testing. Lest programs were 
u,\si :iu'J to avoid dup 1 i ca t i on and to require on Ly the minimum tests 
necessary, subject to consi dv ra L ions ot Hardware criticality and com* 
ploxilv. Flio Ln t Luonoo ol t ho hardware Criticality Category (see 
Sv-v-i jon X) was to omphas i/.r writ icat Lon b\ Lost lor Category i hard- 
ware , by c onib i na t i ons ol tost and assessment. Lor Category 2, and b\ 
assessment rather than test (where feasible) for Categories 3 and 4. 

2 . Test Types 

a. Development Tests . Development tests, as necessary, 
were performed to acquire data to support the design and development 
process; to verify feasibility of the design approach by evaluating 
hardware performance, design margins and/or failure modes under simu- 
lated or actual environmental conditions; and to provide confidence in 
the ability of the hardware to pass qualification testa by verifying 
selected performance/design requirements. Hardware used for develop- 
ment testing was representative of, but not necessarily identical to, 
the flight experiment hardware. A Development Test Specification was 
prepared bv the liD for each development test and submitted tor KDC 
review. Test procedures and a report for each development test were 
prepared bv the HD and made available at appropriate development mile- 
S t One s . 

b. Qua I i 1 i c a t i on T e s t s . Oua L i t i eat ion lusts were per- 
lonmd to verity that the design met the technical requirements ot 

i ;u its, assuring operational suit ability in t he anticipated environ- 
ghialil icat ion test hardware was required to be ident icai in 
eoni i aural ion and. prelect ion prorrssi n?; I o (In- 1 light hardware. A 
ghiaii l ivdl ion lest Spec i i Leal i on and procedures w\ iv prepared b\ the 
I'.l) and submitted l or i.LX i\v i cu « A iormai report oi qualii icat ion 
test ia suits was submi t tod l or KLX approval at rumpli t i on ot tin tests, 
i'ju- qualituat ion t« st program was to be scheduled such that there was 
sut t i c i e n t time I o a l Low* lor pos s i i> 1 e i a L 1 u res , rework du t i n g l <• s t i n g , 
and preparation, review and approval ol the final test reporl , prior to 
acceptance ot the t Light hardware. 

General requirements tor qua L if ieat ion testing, were; 

(L) Qualii icat ion tests were to be conduct eJ UL Lhe 
Highest practical Level ot hardware assembly. 

(2) Li qua I i t ic.it ion tests were to be conducted on tin 
i nt ire er.d item, then accept ;incr tests were conducted on qua i i L i eat ion 
* * :■. i : i a raw a m prior t o qua 1 i l i c a t i on n st s in i n n. eimJuci i 2. 

^ 0 ijuciiec ol liie quaiilU.uion tests loilewi-u ■ .n 
■ . { j" , emu r i v. h i c n t a e i ;i\ i niiii'.H it t s Were to in e a c oun t <. mu Uc ! i n 
i t i n. nardwar* . 
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(4) Tests to determine whether the qualification test 
hardware was performing within specification tolerances were conducted 
alter each environmental exposure, and during the exposure period it 
the flight hardware was required to operate in that environment. 


(5) Qualification tests were performed under strict 
control of environments and test procedures. Adjustment or tuning of 
qualification test hardware was not permitted during tests unless it 
was normal for in-service operation. 

(6) Where redundancy in design existed, the qualifica- 
tion tests assured that each redundancy was qualified* 

(7) If the design configuration or manufacturing pro- 
cesses were changed after acceptance tests on qualif ication test hard- 
ware were initiated, any differences existing between the qualification 
test hardware and the flight and backup hardware invalidated verifica- 
tion and required repeating the qualification test* 

(8) Qualification tests were to be completed prior 
to the delivery of flight or backup hardware. 

(9) Where considered necessary, components of qualifi- 
cation test hardware were disassembled after testing was completed, and 
inspected to determine margins of safety and potential failure modes. 

(10) Types of Test Environments: Humidity; salt, fog; 

high temperature (160°F on Sky lab); low temperature (-40°F on Skylab); 
shock; fungus; positive pressure (for hermetically sealed equipment); 
acceleration; vibration (sinusoidal resonance search, sinusoidial 
cycling, and random vibration); acoustic noise; altitude or space simu- 
lation; and atmospheric compatibility (oxygen, nitrogen, or two-gas en- 
vironment) . 

c. Acceptance Tests. Acceptance tests were conducted to 
verify the performance and configuration of each experiment hardware 
end item at the time of its acceptance bv the Government or delivery 
to another NASA center. The ED prepared (subject to EDC review) an 
Acceptance Test Specification, defining the limits and methods for 
each test, and Acceptance Test Procedures based on this specification. 
Data sheets were prepared showing the results of ail acceptance tests 
performed . 

General requirements for acceptance testing were; 

(1) Environmental tests were included in acceptance 
tests in instances where a type' of manufacturing t law could not be 
detected bv inspection or other nondestructive means (e.g., conduct- 
ing a vibration test on electronic equipment t o i ind iaulty solder 
joints) . 
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(2) The severity, duration, and number ol U'SLs wore 
constrained so as not to rosuit in ove rs tress ing or degradation oi the 
hardware performance capability. 

(i) Where possible, all normal, alternate, redundant 
and emergency operational modes were tested. 

(4) The hardware was calibrated and aligned prior to 
conducting acceptance tests. 

(5) Acceptance tests were performed under strict con- 
trol of environments and test procedures. Adjustment or tuning of 
hardware was not permitted during acceptance testing unless it was 
normal for in-service operation. 

(6) Any repairs, modifications or replacements after 
completion of acceptance tests required retesting to assure the accept- 
ability of the change. 


B. Integration Phase 

1. Requirements . Integration tests were performed to verify 
those interface requirements that could not be formally verified at 
the individual experiment hardware level. General integration test 
requirements were originally baselined in the ERD, including an ex- 
periment hardware flow diagram from the KD through the module integra- 
tion and launch sites, types of lesls at each s*ie and associated spe- 
cial constraints. These requirements and constraints were later ampli- 
fied and updated in the L1TRS documents, which reflected concurrence 

oi. all agencies involved (i.e , the ED , EDC , EIC, Module Development 
Center and Contractor, as applicable). The Module Development Center/ 
eon tractor then developed the detailed TCRSD, covering integration 
LeSLing at boLh module aud launch sites. The TCRSDs contained detailed 
requirements for each test, criteria tor judging th-- success of the 
test, and any special constraints. From these detailed requirements, 
the site responsible for conducting the test prepared detailed test 
procedures to satisfy each requirement. At module integration sites, 
satisfaction of the requirements was a constraint on acceptance of the 
module. At the launch site, satisfaction of the requirements was a 
constraint on flight. readiness. 

2. Test Types . Normally, ail of the following tests (as appli- 
cable) were performed in the initial experiment integration at the module 
site; ideally, only minimal integrated systems testing was performed on 
experiments at the launch site. However, if it was necessarv to remove 
an experiment for calibration, maintenance or modification (or if its 
interfaces were otherwise disturbed) at any lime- alter module integra- 
tion, a L 1 applicable integration tests had to be repealed prior to tie 
launch site inteprnt*d systems test. 
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a. Receiving and Inspection (R&I). Whenever hardware 
was delivered to a site, the equipment and its accompanying data pack- 
age were inspected for completeness and any evidence of physical damage. 
The hardware was not actually operated during R&I unless there was an 
indication of physical damage during shipment. 

b. Pre -Installation Tests (PIT). Following R&I, the hard- 
ware was delivered to a clean room (normally class 100,000), where it 
was set up and tested using experiment GSE. Testing was limited to 
that needed either to verify that baseline calibration data remained 
valid or to determine a new data baseline prior to mating the experiment 
to the flight vehicle. This baseline data (collected either during the 
PIT or daring the earlier acceptance test at the ED site) was needed 
prior to system testing on board the module for comparison with data 
collected during the module system test, in order to determine the 
effect of module environment (electrical, SCI, etc) upon the exper ime nt . 

c. Functional-Interface Verification Test (FIV). The objec- 
tives of these tests were strictly limited to verification of all inter- 
faces with the module. FIV began with verification of mechanical inter- 
faces by mounting the experiment in the module. If installation of the 
experiment involved a part of the module primary pressure structure, the 
seal of the experiment was leak tested following installation. Following 
mechanical installation in the module, polarity of the module power input 
at the experiment interface was checked. A megger-ohm test was performed 
upon the experiment prior to electrical mating, to verify that the ex- 
periment hardware was properly isolated from the module and Lhat experi- 
ment input impedances met interface requirements. Using a "break-out 
box'* between the module power cable and the experiment power connector, 
measured power was applied to the experiment and calculations were made 
to verify the experiment power profile. Following these power checks, 
the power connector was mated directly and the experiment was operated 
under flight conditions (as far as practicality would permit) to verify 
the remaining experiment electrical interfaces. All modes ol the ex- 
periment operation were not functioned unless an interface was involved 
that would not be tested otherwise. 

d. Integrated Systems Tests. Following successful comple- 
tion of all interface verifications of individual experiments, integrated 
system tests were conducted to verify that experiments and module systems 
could play together without degradation of the performance of either. 
These tests were characterized primarily as electromagnetic compatibili- 
ty tests, and were performed utilizing existing flight plans and check- 
lists, with flight crew participation, Lo the greatest extent possible. 
The tests were evaluated by comparison ol their data with baseline data 
provided by the experiment acceptance and/or PIT tests. 
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